Re: Making CASE error handling less surprising - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Making CASE error handling less surprising
Date
Msg-id 20200724171345.cdbazcpe7rl2zlez@alap3.anarazel.de
Whole thread Raw
In response to Re: Making CASE error handling less surprising  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Making CASE error handling less surprising  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Hi,

On 2020-07-24 19:03:30 +0200, Pavel Stehule wrote:
> pá 24. 7. 2020 v 18:49 odesílatel Andres Freund <andres@anarazel.de> napsal:
> > Wouldn't the rule that I proposed earlier, namely that sub-expressions
> > that involve only "proper" constants continue to get evaluated even
> > within CASE, largely address that?
> >
> 
> It doesn't solve a possible performance problem with one shot (EXECUTE stmt
> plpgsql) queries, or with parameterized queries

What precisely are you thinking of here? Most expressions involving
parameters would still get constant evaluated - it'd just be inside CASE
etc that they wouldn't anymore? Do you think it's that common to have a
parameter reference inside an expression inside a CASE where it's
crucial that that parameter reference gets constant evaluated? I'd think
that's a bit of a stretch.

Your earlier example of a WHEN ... THEN upper('constant') ... would
still have the upper('constant') be evaluated, because it doesn't
involve a parameter. And e.g. THEN upper('constant') * $1 would also
still have the upper('constant') be evaluated, just the multiplication
with $1 wouldn't get evaluated.


I'm not sure what you're concerned about with the one-shot bit?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Soumyadeep Chakraborty
Date:
Subject: Re: [Patch] ALTER SYSTEM READ ONLY
Next
From: Andres Freund
Date:
Subject: Re: Improving connection scalability: GetSnapshotData()