From: Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Cc: 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>
Date: 2019-09-17 00:04:29
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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:
The Russian Postgres Company

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Nikita Glukhov 2019-09-17 00:07:55 Re: SQL/JSON: functions
Previous Message Nikita Glukhov 2019-09-16 23:48:12 Re: SQL/JSON: JSON_TABLE