Robert Haas wrote: > On Tue, Sep 21, 2010 at 7:05 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: > >> I don't understand the argument that we need type input functions to > >> be protected by a savepoint. ?That seems crazy to me. ?We're taking a > >> huge performance penalty here to protect against something that seems > >> insane to me in the first instance. ?Not to mention cutting ourselves > >> off from really important features, like the ability to recover from > >> errors during COPY. ?I don't understand why we can't just make some > >> rules about what type input functions are allowed to do. > > > > 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. (I assume > there is something, but I don't know what it is...)
That would be interesting. You would need to flag that this was not a longjump requiring cleanup, but the harder part would be getting back to where the error occurred. I guess you could rerun the query. :-| -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
