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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Review: UNNEST (and other functions) WITH ORDINALITY
Дата
Msg-id 22765.1372211228@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Review: UNNEST (and other functions) WITH ORDINALITY  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Review: UNNEST (and other functions) WITH ORDINALITY  (Greg Stark <stark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Possible bug in CASE evaluation
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Reduce maximum error in tuples estimation after vacuum.