Horton

Re: SQL/JSON revisited

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>, Andrew Dunstan <andrew@dunslane.net>
Cc: Amit Langote <amitlangote09@gmail.com>, Andres Freund <andres@anarazel.de>, vignesh C <vignesh21@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, e.indrupskaya@postgrespro.ru
Date: 2023-03-28T06:07:23Z
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.

Commits

  1. Add SQL/JSON query functions

  2. Add soft error handling to some expression nodes

  3. Adjust populate_record_field() to handle errors softly

  4. Refactor code used by jsonpath executor to fetch variables

  5. Code review for recent SQL/JSON commits

  6. Fix inconsistencies and style issues in new SQL/JSON code

  7. Don't install postmaster symlink anymore

  8. Revert SQL/JSON features

  9. Doc: standardize markup a bit more.