Horton

Re: SQL/JSON features for v15

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@anarazel.de>
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-23T17:33:42Z
Lists: pgsql-hackers 
On Tue, Aug 23, 2022 at 1:23 PM Andres Freund <andres@anarazel.de> wrote:
> > But that's exactly what I'm complaining about. Catching an error that
> > unwound a bunch of stack frames where complicated things are happening
> > is fraught with peril. There's probably a bunch of errors that could
> > be thrown from somewhere in that code - out of memory being a great
> > example - that should not be caught.
>
> The code as is handles this to some degree. Only ERRCODE_DATA_EXCEPTION,
> ERRCODE_INTEGRITY_CONSTRAINT_VIOLATION are caught, the rest is immediately
> rethrown.

AFAIK, Tom has rejected every previous effort to introduce this type
of coding into the tree rather forcefully. What makes it OK now?

> I'm not sure what the general alternative is though. Part of the feature is
> generating a composite type from json - there's just no way we can make all
> possible coercion pathways not error out. That'd necessitate requiring all
> builtin types and extensions types out there to provide input functions that
> don't throw on invalid input and all coercions to not throw either. That just
> seems unrealistic.

Well, I think that having input functions report input that is not
valid for the data type in some way other than just chucking an error
as they'd also do for a missing TOAST chunk would be a pretty sensible
plan. I'd support doing that if we forced a hard compatibility break,
and I'd support that if we provided some way for old code to continue
running in degraded mode. I haven't thought too much about the
coercion case, but I suppose the issues are similar. What I don't
support is saying -- well, upgrading our infrastructure is hard, so
let's just kludge it.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

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