Andres Freund <and...@anarazel.de> writes:
> On 2022-08-23 12:26:55 -0400, Robert Haas 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.
That's still a lot of territory, considering how nonspecific most
SQLSTATEs are. Even if you can prove that only the intended cases
are caught today, somebody could inadvertently break it next week
by using one of those codes somewhere else.
I agree with the upthread comments that we only need/want to catch
foreseeable incorrect-input errors, and that the way to make that
happen is to refactor the related type input functions, and that
a lot of the heavy lifting for that has been done already.
regards, tom lane
