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
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? |