Re: SQL/JSON: FOR ORDINALITY bug

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: SQL/JSON: FOR ORDINALITY bug
Дата
Msg-id CAKFQuwb2xTbk7F8L55O1RJQm=gV1oAOtuCsMqQ37g9ufQh-9vQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: SQL/JSON: FOR ORDINALITY bug  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: SQL/JSON: FOR ORDINALITY bug
Список pgsql-hackers
On Tue, May 3, 2022 at 5:27 PM Andrew Dunstan <andrew@dunslane.net> wrote:

On 2022-05-03 Tu 11:19, Erik Rijkers wrote:
> Hi
>
> I've copied some statements from the .pdf called:
> "TECHNICAL REPORT ISO/IEC TR 19075-6   First edition 2017-03
> Part SQL Notation support 6: (JSON) for JavaScript Object"
> (not available anymore although there should be a similar replacement
> file)
>
> In that pdf I found the data and statement (called 'table 15' in the
> .pdf) as in the attached bash file.  But the result is different: as
> implemented by 15devel, the column rowseq is always 1.  It seems to me
> that that is wrong; it should count 1, 2, 3 as indeed the
> example-result column in that pdf shows.
>
> What do you think?
>
>

Possibly. 


I don't see how rowseq can be anything but 1.  Each invocation of json_table is given a single jsonb record via the lateral reference to bookclub.jcol.  It produces one result, having a rowseq 1.  It does this for all three outer lateral reference tuples and thus produces three output rows each with one match numbered rowseq 1.

David J.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: testclient.exe installed under MSVC
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To: