Re: What happened to the is_<type> family of functions proposal?

On Tue, Sep 21, 2010 at 7:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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...)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company