Re: Review: UNNEST (and other functions) WITH ORDINALITY - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Review: UNNEST (and other functions) WITH ORDINALITY
Date
Msg-id 22765.1372211228@sss.pgh.pa.us
Whole thread Raw
In response to Re: Review: UNNEST (and other functions) WITH ORDINALITY  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Review: UNNEST (and other functions) WITH ORDINALITY  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
> ... and if arr1, 2 and 3 are exactly the same length, this creates a
> coordinated dataset.   I can even use the unnest_ordinality() extension
> function to get the ordinality of this combined dataset:

> SELECT id,
>     (unnest_ordinality(arr1)).element_number as array_index,
>     unnest(arr1) as arr1,
>     unnest(arr2) as arr2,
>     unnest(arr3) as arr3
> FROM lotsarrays;

> There are reasons why this will be complicated to implement WITH
> ORDINALITY; DF, Andrew and I discussed them on IRC.  So allowing WITH
> ORDINALITY in the target list is a TODO, either for later in 9.4
> development, or for 9.5.

Some of the rest of us would like to hear those reasons, because my
immediate reaction is that the patch must be broken by design.  WITH
ORDINALITY should not be needing to mess with the fundamental evaluation
semantics of SRFs, but it sure sounds like it is doing so if that case
doesn't work as expected.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Possible bug in CASE evaluation
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Reduce maximum error in tuples estimation after vacuum.