Re: Review: UNNEST (and other functions) WITH ORDINALITY

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Review: UNNEST (and other functions) WITH ORDINALITY
Date: 2013-06-26 01:47:08
Message-ID: 22765.1372211228@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2013-06-26 02:10:15 Re: Reduce maximum error in tuples estimation after vacuum.
Previous Message Tom Lane 2013-06-26 01:32:36 Re: Possible bug in CASE evaluation