Re: SQL/JSON revisited

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: SQL/JSON revisited
Дата
Msg-id 20230327185456.wbb5gchworsu3hf7@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: SQL/JSON revisited  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: SQL/JSON revisited  (Justin Pryzby <pryzby@telsasoft.com>)
Re: SQL/JSON revisited  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Re: SQL/JSON revisited  (Erik Rijkers <er@xs4all.nl>)
Список pgsql-hackers
Docs amended as I threatened.  Other than that, this has required more
changes than I thought it would.  For one thing, I've continued to
adjust the grammar a little bit, hopefully without breaking anything (at
least, the tests continue to work).  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.  Also,
the fact that we have a_expr on the third one but c_expr on the second
bothers me on consistency grounds; but really we should have a separate
production for things that can be JSON field names.

(I also removed json_object_constructor_args_opt and json_object_args as
separate productions, because I didn't see that they got us anything.)

I also noticed that we had a "string of skipped keys" thing in json.c
that was supposed to be used to detect keys already used but with only
NULL values; however, that stuff had already been rewritten by Nikita on
July 2020 to use a hash table, so the string itself was being built but
uselessly so AFAICS.  Removed that one.

I added a bunch of comments in several places, and postponed addition of
a couple of structs that are not needed for this part of the features.
Some of these will have to come back with the IS JSON support (0002 in
the original set).

Anyway, barring objections or further problems, I intend to get this one
pushed early tomorrow.  For the curious, I've pushed it here
https://github.com/alvherre/postgres/tree/sqljson-constructors
and the tests are currently running here:
https://cirrus-ci.com/build/5468150918021120

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"La experiencia nos dice que el hombre peló millones de veces las patatas,
pero era forzoso admitir la posibilidad de que en un caso entre millones,
las patatas pelarían al hombre" (Ijon Tichy)

Вложения

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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: pgsql: amcheck: Fix verify_heapam for tuples where xmin or xmax is 0.
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: running logical replication as the subscription owner