Tag: pg95

Waiting for 9.5 – Event Trigger for table_rewrite

On 7th of December, Simon Riggs committed patch:

Event Trigger for table_rewrite
 
Generate a table_rewrite event when ALTER TABLE
attempts to rewrite a table. Provide helper
functions to identify table and reason.
 
Intended use case is to help assess or to react
to schema changes that might hold exclusive locks
for long periods.
 
Dimitri Fontaine, triggering an edit by Simon Riggs
 
Reviewed in detail by Michael Paquier

Continue reading Waiting for 9.5 – Event Trigger for table_rewrite

Waiting for 9.5 – Support arrays as input to array_agg() and ARRAY(SELECT …).

On 25th of November, Tom Lane committed patch:

Support arrays as input to array_agg() and ARRAY(SELECT ...).
 
These cases formerly failed with errors about "could not find array type
for data type".  Now they yield arrays of the same element type and one
higher dimension.
 
The implementation involves creating functions with API similar to the
existing accumArrayResult() family.  I (tgl) also extended the base family
by adding an initArrayResult() function, which allows callers to avoid
special-casing the zero-inputs case if they just want an empty array as
result.  (Not all do, so the previous calling convention remains valid.)
This allowed simplifying some existing code in xml.c and plperl.c.
 
Ali Akbar, reviewed by Pavel Stehule, significantly modified by me

Continue reading Waiting for 9.5 – Support arrays as input to array_agg() and ARRAY(SELECT …).

Waiting for 9.5 – BRIN: Block Range Indexes.

On 7th of November, Alvaro Herrera committed patch:

BRIN is a new index access method intended to accelerate scans of very
large tables, without the maintenance overhead of btrees or other
traditional indexes.  They work by maintaining "summary" data about
block ranges.  Bitmap index scans work by reading each summary tuple and
comparing them with the query quals; all pages in the range are returned
in a lossy TID bitmap if the quals are consistent with the values in the
summary tuple, otherwise not.  Normal index scans are not supported
because these indexes do not store TIDs.
 
As new tuples are added into the index, the summary information is
updated (if the block range in which the tuple is added is already
summarized) or not; in the latter case, a subsequent pass of VACUUM or
the brin_summarize_new_values() function will create the summary
information.
 
For data types with natural 1-D sort orders, the summary info consists
of the maximum and the minimum values of each indexed column within each
page range.  This type of operator class we call "Minmax", and we
supply a bunch of them for most data types with B-tree opclasses.
Since the BRIN code is generalized, other approaches are possible for
things such as arrays, geometric types, ranges, etc; even for things
such as enum types we could do something different than minmax with
better results.  In this commit I only include minmax.
 
Catalog version bumped due to new builtin catalog entries.
 
There's more that could be done here, but this is a good step forwards.
 
Loosely based on ideas from Simon Riggs; code mostly by Álvaro Herrera,
with contribution by Heikki Linnakangas.
 
Patch reviewed by: Amit Kapila, Heikki Linnakangas, Robert Haas.
Testing help from Jeff Janes, Erik Rijkers, Emanuel Calvo.
 
PS:
  The research leading to these results has received funding from the
  European Union's Seventh Framework Programme (FP7/2007-2013) under
  grant agreement n° 318633.

Continue reading Waiting for 9.5 – BRIN: Block Range Indexes.

Waiting for 9.5 – Implement SKIP LOCKED for row-level locks

On 7th of October, Alvaro Herrera committed patch:

Implement SKIP LOCKED for row-level locks
 
This clause changes the behavior of SELECT locking clauses in the
presence of locked rows: instead of causing a process to block waiting
for the locks held by other processes (or raise an error, with NOWAIT),
SKIP LOCKED makes the new reader skip over such rows.  While this is not
appropriate behavior for general purposes, there are some cases in which
it is useful, such as queue-like tables.
 
Catalog version bumped because this patch changes the representation of
stored rules.
 
Reviewed by Craig Ringer (based on a previous attempt at an
implementation by Simon Riggs, who also provided input on the syntax
used in the current patch), David Rowley, and Álvaro Herrera.
 
Author: Thomas Munro

Continue reading Waiting for 9.5 – Implement SKIP LOCKED for row-level locks

Waiting for 9.5 – Row-Level Security Policies (RLS)

On 19th of September, Stephen Frost committed patch:

Row-Level Security Policies (RLS)
 
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table.  Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
 
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner.  Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
 
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used.  If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
 
By default, row security is applied at all times except for the
table owner and the superuser.  A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE.  When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
 
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
 
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
 
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
 
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
 
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.

Continue reading Waiting for 9.5 – Row-Level Security Policies (RLS)

Waiting for 9.5 – Add width_bucket(anyelement, anyarray).

On 9th of September, Tom Lane committed patch:

Add width_bucket(anyelement, anyarray).
 
This provides a convenient method of classifying input values into buckets
that are not necessarily equal-width.  It works on any sortable data type.
 
The choice of function name is a bit debatable, perhaps, but showing that
there's a relationship to the SQL standard's width_bucket() function seems
more attractive than the other proposals.
 
Petr Jelinek, reviewed by Pavel Stehule

Continue reading Waiting for 9.5 – Add width_bucket(anyelement, anyarray).

Waiting for 9.5 – Add psql PROMPT variable showing which line of a statement is being edited.

On 2nd of September, Andres Freund committed patch:

Add psql PROMPT variable showing which line of a statement is being edited.
 
The new %l substitution shows the line number inside a (potentially
multi-line) statement starting from one.
 
Author: Sawada Masahiko, heavily editorialized by me.
Reviewed-By: Jeevan Chalke, Alvaro Herrera

Continue reading Waiting for 9.5 – Add psql PROMPT variable showing which line of a statement is being edited.