Re: SQL/JSON: FOR ORDINALITY bug - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: SQL/JSON: FOR ORDINALITY bug
Date
Msg-id 8ea2cc65-1fe5-7baa-0afa-8048295901bc@dunslane.net
Whole thread Raw
In response to SQL/JSON: FOR ORDINALITY bug  (Erik Rijkers <er@xs4all.nl>)
Responses Re: SQL/JSON: FOR ORDINALITY bug
List pgsql-hackers
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. 


Here's what the standard says in section 7.11 in I think the relevant
bit of mindbogglingly impenetrable prose:


General Rules
1)
If a <table primary> simply contains a <JSON table primitive> JTP, then:
a) If the value of the <JSON context item> simply contained in the <JSON
API common syntax> is the null value, then the result of <JSON table
primitive> is an empty table and no further General Rules of this
Subclause are applied.
b) Let JACS be the <JSON API common syntax> simply contained in JTP.
c) Let JTEB be the <JSON table error behavior> simply contained in JTP.
d) The General Rules of Subclause 10.14, “<JSON API common syntax>”, are
applied with JACS as JSON API COMMON SYNTAX; let ROWST be the STATUS and
let ROWSEQ be the SQL/JSON SEQUENCE returned from the application of
those General Rules.
460
Foundation (SQL/Foundation)
e) Case:
i) If ROWST is an exception condition, then
Case:
1) If JTEB is ERROR, then the exception condition ROWST is raised.
2) Otherwise, the result of JTP is an empty table.
ii) Otherwise, let NI be the number of SQL/JSON items in ROWSEQ, let Ij,
1 (one) ≤ j ≤ NI, be those SQL/JSON items in order, let NCD be the
number of <JSON table primitive column definition>s contained in JTP,
and let JTCDi, 1 (one) ≤ i ≤ NCD, be those <JSON table primitive column
definition>s.
For all j, 1 (one) ≤ j ≤ NI, and for all i, 1 (one) ≤ i ≤ NCD, the value
of the i-th column of the j-th row in the result of JTP is determined as
follows:
Case:
1) If JTCDi is a <JSON table ordinality column definition>, then the
value of the i-th column
of the j-th row is j.


Maybe some language lawyer can turn that into comprehensible English.

This should probably be an open item for release 15, but I don't really
know what the precise behaviour should be, so it's hard to modify it.

If we can't get it right maybe we should disable the "WITH ORDINALITY"
clause, although that would be a pity.


cheers


andrew


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




pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: strange slow query - lost lot of time somewhere
Next
From: Andrew Dunstan
Date:
Subject: Re: testclient.exe installed under MSVC