From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
cc: Vik Fearing <vik@postgresfriends.org>,
        =?UTF-8?Q?Marek_Malevi=C4=8D?= <marek@malevicovi.net>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: Broken type checking for empty subqueries
In-reply-to: 
 <CAApHDvpeM708DFpiQG=w3XmRreGvxhN9WuFUs8xYa__VV1pWEg@mail.gmail.com>
References: <7e55db68-7169-4e43-363e-947c79ba7922@malevicovi.net>
 <42808eee-9a68-cfbd-924c-db895d13f9c0@postgresfriends.org>
 <CAApHDvppXNM1etHZZ_8=t2jmqv-LyddtR8P5bUYkjiWwJZbeng@mail.gmail.com>
 <960060.1695913059@sss.pgh.pa.us>
 <CAApHDvpeM708DFpiQG=w3XmRreGvxhN9WuFUs8xYa__VV1pWEg@mail.gmail.com>
Comments: In-reply-to David Rowley <dgrowleyml@gmail.com>
	message dated "Fri, 29 Sep 2023 10:10:33 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1103245.1695938021.1@sss.pgh.pa.us>
Date: Thu, 28 Sep 2023 17:53:41 -0400
Message-ID: <1103246.1695938021@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1103246.1695938021%40sss.pgh.pa.us>
Precedence: bulk

David Rowley <dgrowleyml@gmail.com> writes:
> On Fri, 29 Sept 2023 at 03:57, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Sadly, I doubt that would cover enough of the problem space to make
>> much difference to people who try to do this sort of thing.

> hmm, I guess it does nothing for stuff like overflow errors since we
> didn't adjust the ereports of those functions:

Yeah.  I suppose we could start trying to expand the use of soft
error reporting, but it'd be a herculean, probably multi-year
task to get to where even "most cases" would be covered.

I was actually wondering after sending my previous message whether
CASE wouldn't do the job for the OP.  We do have a rule that once
a CASE test expression has reduced to constant-true or constant-false,
we skip const-folding for CASE arms that are thereby proven unreachable.
Thus for instance

regression=# select case when 1 < 2 then 42 else 1/0 end;
 case 
------
   42
(1 row)

The big trick in using this is to understand what is covered by
const-folding and what is not.  Initial conversion of a literal string
isn't, because that's done at parse time.  So this still fails:

regression=# select case when 1 < 2 then 42 else 'foo'::int end;
ERROR:  invalid input syntax for type integer: "foo"
LINE 1: select case when 1 < 2 then 42 else 'foo'::int end;
                                            ^

but you can get around that like this:

regression=# select case when 1 < 2 then 42 else 'foo'::text::int end;
 case 
------
   42
(1 row)

because the text-to-int conversion is considered a run-time not
parse-time operation.

So I wonder whether that weird-looking sub-select couldn't be converted to
a simple SELECT CASE with both more readability and better future-proofing
against optimizer improvements.

Another way is to push it all into procedural logic, ie a plpgsql function
that doesn't try to evaluate the problematic expression until it's
checked the test expression.

			regards, tom lane