From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Erik Rijkers <er(at)xs4all(dot)nl>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: SQL/JSON: FOR ORDINALITY bug |
Date: | 2022-05-04 00:39:41 |
Message-ID: | CAKFQuwb2xTbk7F8L55O1RJQm=gV1oAOtuCsMqQ37g9ufQh-9vQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 3, 2022 at 5:27 PM Andrew Dunstan <andrew(at)dunslane(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2022-05-04 02:23:57 | Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To: |
Previous Message | Andrew Dunstan | 2022-05-04 00:34:06 | Re: testclient.exe installed under MSVC |