Re: SQL/JSON revisited
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Amit Langote <amitlangote09@gmail.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Andres Freund <andres@anarazel.de>, vignesh C <vignesh21@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, e.indrupskaya@postgrespro.ru
Date: 2023-03-27T18:54:56Z
Lists: pgsql-hackers
Attachments
- v12-0001-SQL-JSON-constructors.patch (text/x-diff)
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)
Commits
-
Add SQL/JSON query functions
- 6185c9737cf4 17.0 landed
-
Add soft error handling to some expression nodes
- aaaf9449ec6b 17.0 landed
-
Adjust populate_record_field() to handle errors softly
- 1edb3b491bee 17.0 landed
-
Refactor code used by jsonpath executor to fetch variables
- faa2b953ba3b 17.0 landed
-
Code review for recent SQL/JSON commits
- 71bfd1543f8b 16.0 landed
-
Fix inconsistencies and style issues in new SQL/JSON code
- 60966f56c3e4 16.0 landed
-
Don't install postmaster symlink anymore
- 37e267335068 16.0 cited
-
Revert SQL/JSON features
- 2f2b18bd3f55 16.0 cited
-
Doc: standardize markup a bit more.
- 47046763c3ed 13.0 cited