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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, "Colin 't Hart" <colinthart(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: What happened to the is_<type> family of functions proposal?
Date: 2010-09-21 23:05:39
Message-ID: 11329.1285110339@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2010-09-21 23:09:27 Re: What happened to the is_<type> family of functions proposal?
Previous Message Kevin Grittner 2010-09-21 22:47:53 Re: Get the offset of a tuple inside a table