Re: SQL/JSON features for v15

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>, Nikita Glukhov <n.gluhov@postgrespro.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Andrew Dunstan <andrew@dunslane.net>, Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, John Naylor <john.naylor@enterprisedb.com>, Amit Langote <amitlangote09@gmail.com>
Date: 2022-08-23T15:55:11Z
Lists: pgsql-hackers
Hi,

On 2022-08-23 10:51:04 -0400, Robert Haas wrote:
> I do not think that using subtransactions as part of the expression
> evaluation process is a sound idea pretty much under any
> circumstances. Maybe if the subtransations aren't commonly created and
> don't usually get XIDs there wouldn't be a big problem in practice,
> but it's an awfully heavyweight operation to be done inside expression
> evaluation even in corner cases. I think that if we need to make
> certain operations that would throw errors not throw errors, we need
> to refactor interfaces until it's possible to return an error
> indicator up to the appropriate level, not just let the error be
> thrown and catch it.

I don't think that's quite realistic - that's the input/output functions for
all types, basically.  I'd be somewhat content if we'd a small list of very
common coercion paths we knew wouldn't error out, leaving things like OOM
aside. Even just knowing that for ->text conversions would be a huge deal in
the context of this patch.  One problem here is that the whole type coercion
infrastructure doesn't make it easy to know what "happened inside" atm, one
has to reconstruct it from the emitted expressions, where there can be
multiple layers of things to poke through.

Greetings,

Andres Freund



Commits

  1. JSON_TABLE: Add support for NESTED paths and columns

  2. Add basic JSON_TABLE() functionality

  3. Add SQL/JSON query functions

  4. Add soft error handling to some expression nodes

  5. Adjust populate_record_field() to handle errors softly

  6. Refactor code used by jsonpath executor to fetch variables

  7. Add more SQL/JSON constructor functions

  8. SQL/JSON: support the IS JSON predicate

  9. SQL/JSON: add standard JSON constructor functions

  10. Revert SQL/JSON features

  11. Numeric error suppression in jsonpath