Re: SQL/JSON: FOR ORDINALITY bug

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.

In response to

Responses

Browse pgsql-hackers by date

  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