From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(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 18:06:02 |
Message-ID: | 1285092165-sup-6030@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Excerpts from Tom Lane's message of mar sep 21 13:41:32 -0400 2010:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> >> On Tue, Sep 21, 2010 at 11:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-09-21 18:06:24 | Re: moving development branch activity to new git repo |
Previous Message | Simon Riggs | 2010-09-21 18:05:02 | Re: Configuring synchronous replication |