Re: plpgsql variable assignment with union is broken - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: plpgsql variable assignment with union is broken
Date
Msg-id CAHyXU0y31SA9JBAXL62zOK1Cw-8S=UvG3V=mrcZGuX_VPD9_0A@mail.gmail.com
Whole thread Raw
In response to Re: plpgsql variable assignment with union is broken  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: plpgsql variable assignment with union is broken  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: plpgsql variable assignment with union is broken  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On Tue, Jan 5, 2021 at 3:40 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> easteregg@verfriemelt.org writes:
> > i found, that the behaviour of variable assignment in combination with union is not working anymore:
> >   DO $$
> >   DECLARE t bool;
> >   begin
> >       t := a FROM ( SELECT true WHERE false ) t(a) UNION SELECT true AS a;
> >   END $$;
>
> > is this an intended change or is it a bug?
>
> It's an intended change, or at least I considered the case and thought
> that it was useless because assignment will reject any result with more
> than one row.  Do you have any non-toy example that wouldn't be as
> clear or clearer without using UNION?  The above sure seems like an
> example of awful SQL code.

What is the definition of broken here?  What is the behavior of the
query with the change and why?

OP's query provably returns a single row and ought to always assign
true as written.  A real world example might evaluate multiple
condition branches so that the assignment resolves true if any branch
is true. It could be rewritten with 'OR' of course.

Is this also "broken"?
  t := a FROM ( SELECT 'something' WHERE _Flag) t(a) UNION SELECT
'something else' AS a WHERE NOT _Flag;

What about this?
SELECT INTO t true WHERE false
UNION select true;

merlin



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: A failure of standby to follow timeline switch
Next
From: Thomas Munro
Date:
Subject: Re: Terminate the idle sessions