Feedback-ID: i131946ab:Fastmail
Message-ID: <327817ff-6c71-fd4b-0b10-f98b5c67e9d0@enterprisedb.com>
Date: Tue, 28 Mar 2023 08:07:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.9.0
Subject: Re: SQL/JSON revisited
Content-Language: en-US
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
References: <20230327185456.wbb5gchworsu3hf7@alvherre.pgsql>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: <20230327185456.wbb5gchworsu3hf7@alvherre.pgsql>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/327817ff-6c71-fd4b-0b10-f98b5c67e9d0%40enterprisedb.com>
Precedence: bulk

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.