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
