Waiting for PostgreSQL 17 – In plpgsql, allow %TYPE and %ROWTYPE to be followed by array decoration.

On 4th of January 2024, Tom Lane committed patch:

In plpgsql, allow %TYPE and %ROWTYPE to be followed by array decoration.
 
This provides the useful ability to declare a variable that is an array
of the type of some other variable or some table column.
 
Quan Zongliang, Pavel Stehule
 
Discussion: https://postgr.es/m/ec4523e1-9e7e-f3ef-f9ce-bafd680ad6f6@yeah.net

Continue reading Waiting for PostgreSQL 17 – In plpgsql, allow %TYPE and %ROWTYPE to be followed by array decoration.

Waiting for PostgreSQL 16 – Add array_sample() and array_shuffle() functions.

On 7th of April 2023, Tom Lane committed patch:

Add array_sample() and array_shuffle() functions.
 
These are useful in Monte Carlo applications.
 
Martin Kalcher, reviewed/adjusted by Daniel Gustafsson and myself
 
Discussion: https://postgr.es/m/9d160a44-7675-51e8-60cf-6d64b76db831@aboutsource.net

Continue reading Waiting for PostgreSQL 16 – Add array_sample() and array_shuffle() functions.

Getting list of unique elements in table, per group

Today, on irc, someone asked interesting question.

Basically she ran a query like:

SELECT a, b, c, d, e, f FROM TABLE ORDER BY a

then, she processed the query to get, for each a array of unique values of b, c, d, e, and f, and then he inserted it back to database, to some other table.

It was a problem, because the table had many rows (millions I would assume), and the whole process was slow.

So, how to make it faster?

Continue reading Getting list of unique elements in table, per group

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.4 – Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.

On 22nd of November, Tom Lane committed patch:

Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.
 
This patch adds the ability to write TABLE( function1(), function2(), ...)
as a single FROM-clause entry.  The result is the concatenation of the
first row from each function, followed by the second row from each
function, etc; with NULLs inserted if any function produces fewer rows than
others.  This is believed to be a much more useful behavior than what
Postgres currently does with multiple SRFs in a SELECT list.
 
This syntax also provides a reasonable way to combine use of column
definition lists with WITH ORDINALITY: put the column definition list
inside TABLE(), where it's clear that it doesn't control the ordinality
column as well.
 
Also implement SQL-compliant multiple-argument UNNEST(), by turning
UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
 
The SQL standard specifies TABLE() with only a single function, not
multiple functions, and it seems to require an implicit UNNEST() which is
not what this patch does.  There may be something wrong with that reading
of the spec, though, because if it's right then the spec's TABLE() is just
a pointless alternative spelling of UNNEST().  After further review of
that, we might choose to adopt a different syntax for what this patch does,
but in any case this functionality seems clearly worthwhile.
 
Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
significantly revised by me

Continue reading Waiting for 9.4 – Support multi-argument UNNEST(), and TABLE() syntax for multiple functions.

Waiting for 9.3 – Add array_remove() and array_replace() functions.

On 11th of July, Tom Lane committed patch:

Add array_remove() and array_replace() functions. <span class="refs"> <span class="head" title="heads/master"><a href="/gitweb/?p=postgresql.git;a=shortlog;h=refs/heads/master">master
 
These functions support removing or replacing array element value(s)
matching a given search value.  Although intended mainly to support a
future array-foreign-key feature, they seem useful in their own right.
 
Marco Nenciarini and Gabriele Bartolini, reviewed by Alex Hunsaker

Continue reading Waiting for 9.3 – Add array_remove() and array_replace() functions.

Waiting for 9.1 – Arrays in PL/Perl

On 18th of February, Alvaro Herrera committed patch:

Convert Postgres arrays to Perl arrays on PL/perl input arguments
 
More generally, arrays are turned in Perl array references, and row and
composite types are turned into Perl hash references.  This is done
recursively, in a way that's natural to every Perl programmer.
 
To avoid a backwards compatibility hit, the string representation of
each structure is also available if the function requests it.
 
Authors: Alexey Klyukin and Alex Hunsaker.
Some code cleanups by me.

Continue reading Waiting for 9.1 – Arrays in PL/Perl

Waiting for 9.1 – FOREACH IN ARRAY

On 16th of February, Tom Lane committed patch:

Add FOREACH IN ARRAY looping to plpgsql.
 
(I'm not entirely sure that we've finished bikeshedding the syntax details,
but the functionality seems OK.)
 
Pavel Stehule, reviewed by Stephen Frost and Tom Lane

Continue reading Waiting for 9.1 – FOREACH IN ARRAY