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

From Pavel Stehule
Subject Re: plpgsql raise - parameters can be expressions
Date
Msg-id Pine.LNX.4.44.0506130737080.16737-100000@kix.fsv.cvut.cz
Whole thread Raw
In response to Re: plpgsql raise - parameters can be expressions  (Michael Glaesemann <grzm@myrealbox.com>)
List pgsql-patches
On Mon, 13 Jun 2005, Michael Glaesemann wrote:

>
> On Jun 13, 2005, at 2:07 PM, Pavel Stehule wrote:
>
> >     I did trivial patch which eliminate limit raise command. Using
> > expressions instead of variables are a little bit expensive, but
> > little.
>
> I'm right in thinking this essentially does the same thing as first
> assigning the value of the expression to a variable and then using
> the variable in the RAISE statement, correct? This patch just
> eliminates the step of assigning the value of the expression to the
> variable? If so, I'd expect the cost to be in line with the cost of
> explicitly assigning to a variable.
>

true, total cost is less

Pavel


pgsql-patches by date:

Previous
From: Michael Glaesemann
Date:
Subject: Re: plpgsql raise - parameters can be expressions
Next
From: Neil Conway
Date:
Subject: Re: plpgsql raise - parameters can be expressions