Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Sep 21, 2010 at 7:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> There are many rules that you could possibly make for type input
>> functions. �But "you cannot throw an error" is not one of them ---
>> or at least, not one that you can usefully expect to be followed
>> for anything more than trivial straightline code.
> OK. This is one of the things I don't understand. Why does throwing
> an error imply that we need to abort the current transaction? Why
> can't we just catch the longjmp() and trundle onwards? Obviously,
> that's unsafe if a pretty wide variety of cases, but if you're just
> scrutinizing the input string (even with a little bit of read-only
> database access) it's not obvious to me what can go wrong.
The problem is to know that "all you did" was scrutinize the input
string. If it's simple straightline code (even with some C library
calls) then you can know that, but then you can write such code without
including any elog(ERROR) in it in the first place. If you are trapping
longjmps then what you'd need to assert is that no error thrown from
anywhere in any of the code reachable from that place represents a
problem that requires transaction abort to clean up after. This gets
unmaintainable remarkably quickly, especially if you invoke anything
as complicated as database access. And then there are asynchronous
error reasons (query cancel) which you shouldn't trap in any case.
regards, tom lane