Horton

Re: SQL/JSON features for v15

Pavel Stehule <pavel.stehule@gmail.com>

View thread View on postgr.es
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>, "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-23T16:06:22Z
Lists: pgsql-hackers 
Hi

út 23. 8. 2022 v 17:55 odesílatel Andres Freund <andres@anarazel.de> napsal:

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

The errors that should be handled are related to json structure errors. I
don't think so we have to handle all errors and all conversions.

The JSON knows only three types - and these conversions can be written
specially for this case - or we can write json io routines to be able to
signal error
without an exception.

Regards

Pavel





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