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
>>
>
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? |