Re: SQL/JSON features for v15
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Nikita Glukhov <n.gluhov@postgrespro.ru>, Tom Lane <tgl@sss.pgh.pa.us>,
Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
"Jonathan S. Katz" <jkatz@postgresql.org>,
Amit Langote <amitlangote09@gmail.com>,
Alvaro Herrera <alvherre@alvh.no-ip.org>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Michael Paquier <michael@paquier.xyz>,
John Naylor <john.naylor@enterprisedb.com>
Date: 2022-09-30T03:05:07Z
Lists: pgsql-hackers
On 2022-09-01 Th 09:54, Nikita Glukhov wrote: > > On 31.08.2022 23:39, Nikita Glukhov wrote: > >> And here is a quick POC patch with an example for COPY and float4 > I decided to go further and use new API in SQL/JSON functions > (even if it does not make real sense now). > > I have added function for checking expressions trees, special > executor steps for handling errors in FuncExpr, CoerceViaIO, > CoerceToDomain which are passed through ExprState.edata. > > Of course, there is still a lot of work: > 1. JIT for new expression steps > 2. Removal of subsidary ExprStates (needs another solution for > ErrorData passing) > 3. Checking of domain constraint expressions > 4. Error handling in coercion to bytea > 5. Error handling in json_populate_type() > 6. Error handling in jsonb::type casts > 7. ... > > > Also I have added lazy creation of JSON_VALUE coercions, which was > not present in previous patches. It really greatly speeds up JIT > and reduces memory consumption. But it requires using of subsidary > ExprStates. > > > jsonb_sqljson test now fails because of points 4, 5, 6. It looks like this needs to be rebased anyway. I suggest just submitting the Input function stuff on its own, I think that means not patches 3,4,15 at this stage. Maybe we would also need a small test module to call the functions, or at least some of them. The earlier we can get this in the earlier SQL/JSON patches based on it can be considered. A few comments: . proissafe isn't really a very informative name. Safe for what? maybe proerrorsafe or something would be better? . I don't think we need the if test or else clause here: + if (edata) + return InputFunctionCallInternal(flinfo, str, typioparam, typmod, edata); + else + return InputFunctionCall(flinfo, str, typioparam, typmod); . I think we should probably cover float8 as well as float4, and there might be some other odd gaps. As mentioned previously, this should really go in a new thread, so please don't reply to this but start a completely new thread. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Commits
-
JSON_TABLE: Add support for NESTED paths and columns
- bb766cde63b4 17.0 landed
-
Add basic JSON_TABLE() functionality
- de3600452b61 17.0 landed
-
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
-
Add more SQL/JSON constructor functions
- 03734a7fed7d 17.0 landed
-
SQL/JSON: support the IS JSON predicate
- 6ee30209a6f1 16.0 landed
-
SQL/JSON: add standard JSON constructor functions
- 7081ac46ace8 16.0 landed
-
Revert SQL/JSON features
- 96ef3237bf74 15.0 landed
- 2f2b18bd3f55 16.0 landed
-
Numeric error suppression in jsonpath
- 16d489b0fe05 12.0 cited