Re: SQL/JSON features for v15 - Mailing list pgsql-hackers

Hi,

On 2022-08-23 12:26:55 -0400, Robert Haas wrote:
> On Tue, Aug 23, 2022 at 11:55 AM Andres Freund <andres@anarazel.de> wrote:
> > 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.
> 
> 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.


> What you (probably) want is to know whether one specific error happened or
> not, and catch only that one. And the error machinery isn't designed for
> that. It's not designed to let you catch specific errors for specific call
> sites, and it's also not designed to be particularly efficient if lots of
> errors need to be caught over and over again. If you decide to ignore all
> that and do it anyway, you'll end up with, at best, code that is
> complicated, hard to maintain, and probably slow when a lot of errors are
> trapped, and at worst, code that is fragile or outright buggy.

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.

I think the best we could without subtransactions do perhaps is to add
metadata to pg_cast, pg_type telling us whether certain types of errors are
possible, and requiring ERROR ON ERROR when coercion paths are required that
don't have those options.

Greetings,

Andres Freund