Re: SQL/JSON revisited

Alexander Law <exclusion@gmail.com>

From: Alexander Lakhin <exclusion@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>, Erik Rijkers <er@xs4all.nl>
Cc: Andrew Dunstan <andrew@dunslane.net>, 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-29T18:00:00Z
Lists: pgsql-hackers
Hi,

29.03.2023 13:27, Alvaro Herrera wrote:
> ... and pushed it now, after some more meddling.
>
> I'll rebase the rest of the series now.

Please look at the several minor issues/inconsistencies,
I've spotted in the commit:

1) s/JSON_ARRRAYAGG/JSON_ARRAYAGG/

2)
check_key_uniqueness vs check_unique
IIUC, these are different names of the same entity.

3)
elog(ERROR, "invalid JsonConstructorExprType %d", ctor->type);
vs
elog(ERROR, "invalid JsonConstructorExpr type %d", ctor->type);
I'd choose the latter spelling as the JsonConstructorExprType entity does not exist.

4)
In the block:
     else
     {
         res = (Datum) 0;
         elog(ERROR, "invalid JsonConstructorExpr type %d", ctor->type);
     }
res is assigned but never used.

5)
(expr [FORMAT json_format]) ->? (expr [FORMAT JsonFormat])
(json_format not found anywhere else)

Best regards,
Alexander



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.