Re: SQL/JSON revisited

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: SQL/JSON revisited
Дата
Msg-id 327817ff-6c71-fd4b-0b10-f98b5c67e9d0@enterprisedb.com
обсуждение исходный текст
Ответ на Re: SQL/JSON revisited  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список 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.




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry