Re: SQL/JSON: JSON_TABLE

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Subject: Re: SQL/JSON: JSON_TABLE
Date: 2019-10-19 15:31:25
Message-ID: CAFj8pRDBiX=tqHJEWKevfatwSPkb4C6bYHvxTYhxrG8mTvJ2+A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

po 30. 9. 2019 v 18:09 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
napsal:

> Hi
>
> so 28. 9. 2019 v 3:53 odesílatel Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>
> napsal:
>
>> Attached 39th version of the patches rebased onto current master.
>>
>>
This patch is still pretty big - it is about 6000 lines (without any
documentation). I checked the standard - and this patch try to implement

JSON_TABLE as part of T821
Plan clause T824
Plan default clause T838.

Unfortunately for last two features there are few documentation other than
standard, and probably other databases doesn't implement these features (I
didn't find it in Oracle, MySQL, MSSQL and DB2) . Can be this patch divided
by these features? I hope so separate review and commit can increase a
chance to merge this code (or the most significant part) in this release.

It is pretty hard to do any deeper review without documentation and without
other information sources.

What do you think?

Regards

Pavel

>
> Regress tests fails on my comp - intel 64bit Linux, gcc 9.2.1
>
> Comments:
>
> * +<->/* Only XMLTABLE and JSON_TABLE are supported currently */
>
> this comment has not sense more. Can be removed. Probably long time there
> will not be new format like XML or JSON
>
> * there are new 600 lines to parse_clause.c, maybe this code can be placed
> in new file parse_jsontable.c ? parse_clause.c is pretty long already
> (json_table has very complex syntax)
>
> *
> +<->if (list_length(ci->passing.values) > 0)
> +<->{
> +<-><-->ListCell *exprlc;
> +<-><-->ListCell *namelc;
> +
>
> It's uncommon usage of list_length function. More common is just "if
> (ci->passing.values) {}". Is there any reason for list_length?
>
> * I tested some examples that I found on net. It works very well. Minor
> issues are white chars for json type. Probably json_table should to trim
> returned values, because after cutting from document, original white chars
> lost sense. It is not a problem jsonb type, that reduce white chars on
> input.
>
> I did only simple tests and I didn't find any other issues than white
> chars problems for json type. I'll continue in some deeper tests. Please,
> prepare documentation. Without documentation there is not clean what
> features are supported. I have to do blind testing.
>
> Regards
>
> Pavel
>
>
>
>
>
>
>
>
>
>> --
>> Nikita Glukhov
>> Postgres Professional: http://www.postgrespro.com
>> The Russian Postgres Company
>>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2019-10-19 15:43:59 Re: Proposal: Make use of C99 designated initialisers for nulls/values arrays
Previous Message Andrew Dunstan 2019-10-19 15:30:49 Re: Backport "WITH ... AS MATERIALIZED" syntax to <12?