Re: SQL/JSON: FOR ORDINALITY bug

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: SQL/JSON: FOR ORDINALITY bug
Дата
Msg-id 90001093-b9b1-f0fe-628c-de168054d86a@dunslane.net
обсуждение исходный текст
Ответ на Re: SQL/JSON: FOR ORDINALITY bug  (Erik Rijkers <er@xs4all.nl>)
Ответы Re: SQL/JSON: FOR ORDINALITY bug  (Erik Rijkers <er@xs4all.nl>)
Список pgsql-hackers
On 2022-05-04 We 10:39, Erik Rijkers wrote:
> Op 04-05-2022 om 13:55 schreef Andrew Dunstan:
>>
>> On 2022-05-03 Tu 20:39, David G. Johnston wrote:
>>> 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
>
>
> After some further experimentation, I now think you must be right, David.
>
> Also, looking at the DB2 docs:
>   https://www.ibm.com/docs/en/i/7.2?topic=data-using-json-table
>     (see especially under 'Handling nested information')
>
> There, I gathered some example data + statements where one is the case
> at hand.  I also made them runnable under postgres (attached).
>
> I thought that was an instructive example, with those
> 'outer_ordinality' and 'inner_ordinality' columns.
>
>

Yeah, I just reviewed the latest version of that page (7.5) and the
example seems fairly plain that we are doing the right thing, or if not
we're in pretty good company, so I guess this is probably a false alarm.
Looks like ordinality is for the number of the element produced by the
path expression. So a path of 'lax $' should just produce ordinality of
1 in each case, while a path of 'lax $[*]' will produce increasing
ordinality for each element of the root array.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




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

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: Query generates infinite loop
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: JSON Functions and Operators Docs for v15