Hi, On 2022-08-23 13:33:42 -0400, Robert Haas wrote: > 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 didn't say it was! I don't like it much - I was just saying that it handles that case to some degree. > > 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. I guess the 'degraded mode' approach is kind of what I was trying to describe with: > 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
