Re: Unexpected results from a query with UNION ALL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrey <adnyre(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Unexpected results from a query with UNION ALL
Date: 2025-01-08 17:01:36
Message-ID: 1665866.1736355696@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I wrote:
> Andrey <adnyre(at)gmail(dot)com> writes:
>> ... but I would expect to get the same result as previously. Is it a bug
>> or am I doing something wrong here?

> It's a surprising result for sure, but I believe it's explained by
> the algorithm for READ COMMITTED [1], specifically the bit about

Actually, on further thought I believe this really is a bug,
because if you change the UNION ALL to UNION it works fine.
It probably used to work with UNION ALL too, but that was a few
decades ago before we started adding optimizations of UNION ALL :-(

I've been poking at this off and on for the last few days, and I've
found three different things that will need to be changed to make
it work again. At least one of them looks too invasive to consider
for back-patch. So don't hold your breath for a proper fix, but
perhaps you could use UNION as a workaround?

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message shammat 2025-01-08 18:39:25 Re: Postgres 17 domains with NOT NULL and pg_get_constraintdef()
Previous Message Alvaro Herrera 2025-01-08 13:10:45 Re: Postgres 17 domains with NOT NULL and pg_get_constraintdef()