Re: plpgsql raise - parameters can be expressions - Mailing list pgsql-patches

From Tom Lane
Subject Re: plpgsql raise - parameters can be expressions
Date
Msg-id 11519.1118710860@sss.pgh.pa.us
Whole thread Raw
In response to Re: plpgsql raise - parameters can be expressions  (Neil Conway <neilc@samurai.com>)
Responses Re: plpgsql raise - parameters can be expressions  (Neil Conway <neilc@samurai.com>)
List pgsql-patches
Neil Conway <neilc@samurai.com> writes:
> Tom Lane wrote:
>> Actually, the reason I didn't do something about RAISE in 8.0 was that
>> I thought we should reconsider the whole design of the statement

> The ensuing discussion on this sounds good to me; should I apply Pavel's
> RAISE patch now, or wait for the subsequent work on specifying a
> particular SQLSTATE?

The patch seems to me to be OK as far as it goes.  I brought up the
other points only because I wanted to be sure that it wouldn't be
inconsistent with the next step; but it seems we're pretty well agreed
that we aren't going to do anything that would break this.  So I have no
problem with applying as-is, rather than waiting for an all-inclusive
patch.

But you had mentioned wanting to look at reducing overhead by using
exec_eval_expr(); were you intending to do that before committing?

As far as the subsequent discussion itself goes, Pavel and I seem to
be pretty unsuccessful at convincing each other of our respective
visions of what an exception ought to be.  Any opinions?  Should
we be taking this thread to -hackers for a wider audience?

            regards, tom lane

pgsql-patches by date:

Previous
From: Neil Conway
Date:
Subject: Re: plpgsql raise - parameters can be expressions
Next
From: Bruce Momjian
Date:
Subject: Re: logfile for psql patch update