Re: SQL/JSON: JSON_TABLE

Поиск
Список
Период
Сортировка
От Nikita Glukhov
Тема Re: SQL/JSON: JSON_TABLE
Дата
Msg-id 94ab028a-07aa-38e5-b184-3d640f642bfb@postgrespro.ru
обсуждение исходный текст
Ответ на Re: SQL/JSON: JSON_TABLE  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: SQL/JSON: JSON_TABLE  (Nikita Glukhov <n.gluhov@postgrespro.ru>)
Список 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 по дате отправления:

Предыдущее
От: Nikita Glukhov
Дата:
Сообщение: Re: SQL/JSON: JSON_TABLE
Следующее
От: Nikita Glukhov
Дата:
Сообщение: Re: SQL/JSON: functions