| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, e(dot)indrupskaya(at)postgrespro(dot)ru |
| Subject: | Re: SQL/JSON revisited |
| Date: | 2023-03-28 06:07:23 |
| Message-ID: | 327817ff-6c71-fd4b-0b10-f98b5c67e9d0@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 27.03.23 20:54, Alvaro Herrera wrote:
> Even so, I was unable to get bison
> to accept the 'KEY name VALUES blah' syntax; it might be a
> fun/challenging project to change the productions that we use for JSON
> names and values:
>
> +json_name_and_value:
> +/* Supporting this syntax seems to require major surgery
> + KEY c_expr VALUE_P json_value_expr
> + { $$ = makeJsonKeyValue($2, $4); }
> + |
> +*/
> + c_expr VALUE_P json_value_expr
> + { $$ = makeJsonKeyValue($1, $3); }
> + |
> + a_expr ':' json_value_expr
> + { $$ = makeJsonKeyValue($1, $3); }
> + ;
>
> If we uncomment the KEY bit there, a bunch of conflicts emerge.
This is a known bug in the SQL standard. Because KEY is a non-reserved
keyword, writing
KEY (x) VALUE y
is ambiguous because KEY could be the keyword for this clause or a
function call key(x).
It's ok to leave it like this for now.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2023-03-28 06:16:36 | Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry |
| Previous Message | Michael Paquier | 2023-03-28 05:56:28 | Re: ALTER TABLE SET ACCESS METHOD on partitioned tables |