Re: Making CASE error handling less surprising

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Chris Travers <chris(dot)travers(at)adjust(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Making CASE error handling less surprising
Date: 2020-07-29 13:53:55
Message-ID: CA+TgmobFdDfY6-q-OEbsnDyCBmBzG3NeEv7z4PRR=EKmYfOK-Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jul 26, 2020 at 1:27 PM Chris Travers <chris(dot)travers(at)adjust(dot)com> wrote:
> The first (probably the best) would be a solution along the lines of yours along with a session-level GUC variable which could determine whether case branches can fold constants.

Bluntly, that seems like a terrible idea. It's great if you are an
expert DBA, because then you can adjust the behavior on your own
system according to what works best for you. But if you are trying to
write portable code that will work on any PostgreSQL instance, you now
have to remember to test it with every possible value of the GUC and
make sure it behaves the same way under all of them. That is a major
burden on authors of tools and extensions, and if we add even three or
four such GUCs with three or four possible values each, there are
suddenly dozens or even hundreds of possible combinations to test. I
think that adding GUCs for this kind of thing is a complete
non-starter for that reason.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-07-29 13:59:02 Re: Making CASE error handling less surprising
Previous Message Robert Haas 2020-07-29 13:47:54 Re: INSERT INTO SELECT, Why Parallelism is not selected?