On Tue, Aug 23, 2022 at 1:23 PM Andres Freund <and...@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
