On Sun, Aug 29, 2010 at 11:23:29AM -0400, Tom Lane wrote:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > I understand now. So it means general advice - don't use a boolean
> > operators in SQL function? This issue should be documented somewhere?
> It has nothing to do with boolean operators, just double evaluation.
I was wondering, wouldn't it be possible to avoid the double evaluation
by simply creating an extra slot for the intermediate value. So you
$1 = CASE WHEN random() < 0.5 THEN NULL ELSE 'x' END
$2 = $1 IS NULL or $1 = ''
Sort of the way WITH works, but then for parts of expressions.
I don't believe currently expressions can refer to Vars at the same
level (it would make projections somewhat messy) but if you could
fix that you could avoid the double evaluation and still have decent
Have a nice day,
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patriotism is when love of your own people comes first; nationalism,
> when hate for people other than your own comes first.
> - Charles de Gaulle
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2010-08-29 18:08:54|
|Subject: Re: performance issue: logical operators are slow inside SQL function: missing optimalization? |
|Previous:||From: Pavel Stehule||Date: 2010-08-29 15:42:44|
|Subject: Re: performance issue: logical operators are slow inside
SQL function: missing optimalization?|