On Wednesday 22 September 2010 01:05:39 Tom Lane 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. > > The poster child for this is of course domain_in(). But even without > that, I don't think you can realistically legislate that no errors be > thrown by something of the complexity of, say, the timestamp input > functions. Just for starters, what of a palloc() failure? Uhm. Isnt a palloc failure a really, really bad example because it will kill the session anyway? FATAL+ is not relevant in that context, right?
Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
