Re: What happened to the is_ family of functions proposal? - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: What happened to the is_ family of functions proposal?
Date
Msg-id 1285092165-sup-6030@alvh.no-ip.org
Whole thread Raw
In response to Re: What happened to the is_ family of functions proposal?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: What happened to the is_ family of functions proposal?
List pgsql-hackers
Excerpts from Tom Lane's message of mar sep 21 13:41:32 -0400 2010:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> >> On Tue, Sep 21, 2010 at 11:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>> The problem here is that putting the exception handling in C doesn't
> >>> make things any better:
> 
> > So we could refactor the input functions so that there's an internal
> > function that returns the accepted datum in the OK case and an ErrorData
> > for the failure case.
> 
> This makes the untenable assumption that there are no elog(ERROR)s in
> the "internal" input function *or anything it calls*.  Short of truly
> massive restructuring, including uglifying many internal APIs to have
> error return codes instead of allowing elog within the callee, you will
> never make this work for anything more complicated than say float8in().

... which is what people want anyway.  I mean, the day someone requests
is_sthcomplex, we could happily tell them that they need to use the
expensive workaround involving savepoints.  I don't think we really need
to support the ones that would require truly expensive refactoring; the
simple ones would cover 99% of the use cases.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Configuring synchronous replication
Next
From: Heikki Linnakangas
Date:
Subject: Re: moving development branch activity to new git repo