Re: pgsql: JSON_TABLE

On 4/5/22 15:05, Oleg Bartunov wrote:
> On Tue, Apr 5, 2022 at 1:31 AM Andrew Dunstan <andrew@dunslane.net> wrote:
>>
>> On 4/4/22 18:16, Erik Rijkers wrote:
>>> Op 04-04-2022 om 22:23 schreef Andrew Dunstan:
>>>> JSON_TABLE
>>> Great that this is now committed!
>>>
>>> I notice one changed item: the NESTED-PATH-phrase does not accept an
>>> alias anymore.  The JSON_PATH v59 patches still had:
>>>
>>> | NESTED PATH json_path_specification [ AS path_name ]
>>>   COLUMNS ( json_table_column [, ...] )
>>>
>>> My complaint is only half-hearted because I don't really understand
>>> what the use of such nested-path aliases are.  But it's a change from
>>> the earlier patch, and the nested-path aliases are used too in the
>>> 2017-03 'Technical report ISO/IEC TR 19075-6', which is as near I have
>>> to a SQL Standard description.
>>>
>>> FWIW, I attach example sql+data from that .pdf from ISO (which is not
>>> online anymore).
>>>
>>>
>> These commits are being staggered. The last code patches will be
>> committed tomorrow.
> as for PostgreSQL 15devel-master/fadb48b00e aliases AS works
>
> SELECT
>   jt.*
> FROM
>   house,
>   JSON_TABLE(js, '$.floor[*]'  AS lvl COLUMNS (
>     level int,
>     NESTED PATH '$.apt[*] ? (@.area > 1000)' AS big COLUMNS (
>       no int
>     )
>   ) PLAN (lvl OUTER big) ) jt;
>  level |   no
> -------+--------
>      1 | (null)
>      2 | (null)
> (2 rows)



Yeah, and I think that's the answer to Erik's question about why we need
it, it's so you have a name you can refer to in the PLAN clause, as in
you example.


cheers


andrew


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