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

From Neil Conway
Subject Re: plpgsql raise - parameters can be expressions
Date
Msg-id 42AE60BA.4040208@samurai.com
Whole thread Raw
In response to Re: plpgsql raise - parameters can be expressions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: plpgsql raise - parameters can be expressions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Tom Lane wrote:
> But you had mentioned wanting to look at reducing overhead by using
> exec_eval_expr(); were you intending to do that before committing?

I'm a bit busy with other matters at the moment, so I'll probably look
at it later. One question is whether we should make use of
exec_eval_expr() by representing the RAISE parameter list as a list of
expressions (each of which would likely be simple enough to evaluate via
ExecEvalExpr()), or whether we want to extend exec_eval_expr() to handle
  expressions that yield multiple attributes.

-Neil

pgsql-patches by date:

Previous
From: Neil Conway
Date:
Subject: hash join: probe both inputs first
Next
From: Tom Lane
Date:
Subject: Re: plpgsql raise - parameters can be expressions