From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Vik Fearing <vik@postgresfriends.org>
Cc: Marek Malevič <marek@malevicovi.net>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Broken type checking for empty subqueries
Date: Thu, 28 Sep 2023 17:53:41 -0400
Message-ID: <1103246.1695938021@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, dgrowleyml@gmail.com, vik@postgresfriends.org, marek@malevicovi.net, pgsql-bugs@lists.postgresql.org
Subject: Re: Broken type checking for empty subqueries
In-Reply-To: <1103246.1695938021@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox