Re: SQL/JSON: JSON_TABLE - Mailing list pgsql-hackers

From Nikita Glukhov
Subject Re: SQL/JSON: JSON_TABLE
Date
Msg-id 94ab028a-07aa-38e5-b184-3d640f642bfb@postgrespro.ru
Whole thread Raw
In response to Re: SQL/JSON: JSON_TABLE  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: SQL/JSON: JSON_TABLE
List pgsql-hackers
On 23.07.2019 16:58, Pavel Stehule wrote:

I got warning

ar crs libpgcommon.a base64.o config_info.o controldata_utils.o d2s.o exec.o f2s.o file_perm.o ip.o keywords.o kwlookup.o link-canary.o md5.o pg_lzcompress.o pgfnames.o psprintf.o relpath.o rmtree.o saslprep.o scram-common.o string.o unicode_norm.o username.o wait_error.>
...skipping...
clauses.c:1076:3: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
 1076 |   if (ExecEvalJsonNeedsSubTransaction(jsexpr, NULL))
      |   ^~
clauses.c:1078:4: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
 1078 |    return true;
      |    ^~~~~~
gcc -Wall -Wmissing-protot
Fixed in 38th version. Thanks.


Regress tests diff is not empty - see attached file
Unfortunately, this is not reproducible on my machine, but really seems to be 
a bug.


some strange fragments from code:

    deparseExpr(node->arg, context);
-   if (node->relabelformat != COERCE_IMPLICIT_CAST)
+   if (node->relabelformat != COERCE_IMPLICIT_CAST &&
+       node->relabelformat == COERCE_INTERNAL_CAST)

There obviously should be

node->relabelformat != COERCE_INTERNAL_CAST
Fixed in 38th version. Thanks.
Now, "format"  is type_func_name_keyword, so when you use it, then nobody 
can use "format" as column name. It can break lot of application. "format" 
is common name. It is relatively unhappy, and it can touch lot of users.
FORMAT was moved to unreserved_keywords in the 38th version. I remember that
there was conflicts with FORMAT, but now it works as unreserved_keyword.


This patch set (JSON functions & JSON_TABLE) has more tha 20K rows. More, there are more than few features are implemented.

Is possible to better (deeper) isolate these features, please? I have nothing against any implemented feature, but it is hard to work intensively (hard test) on this large patch. JSON_TABLE has only 184kB, can we start with this patch?

SQLJSON_FUNCTIONS has 760kB - it is maybe too much for one feature, one patch.

Patch 0001 is simply a squash of all 7 patches from the thread 
"SQL/JSON: functions".  These patches are preliminary for JSON_TABLE.

Patch 0002 only needs to be review in this thread.

--
Nikita Glukhov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

pgsql-hackers by date:

Previous
From: Nikita Glukhov
Date:
Subject: Re: SQL/JSON: JSON_TABLE
Next
From: Nikita Glukhov
Date:
Subject: Re: SQL/JSON: functions