Re: What happened to the is_<type> family of functions proposal?
Alvaro Herrera <alvherre@commandprompt.com>
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Colin 't Hart <colinthart@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2010-09-21T18:06:02Z
Lists: 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