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
-
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