From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
cc: zuming.jiang@inf.ethz.ch, Alexander Korotkov <aekorotkov@gmail.com>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18261: Inconsistent results of SELECT affected by joined
 subqueries
In-reply-to: 
 <CAMbWs48_EAPrc_C5qvK2WGvydHvht1JUnXwer9FVeU7t_zA+MQ@mail.gmail.com>
References: <18261-2a75d748c928609b@postgresql.org>
 <CAMbWs48_EAPrc_C5qvK2WGvydHvht1JUnXwer9FVeU7t_zA+MQ@mail.gmail.com>
Comments: In-reply-to Richard Guo <guofenglinux@gmail.com>
	message dated "Thu, 28 Dec 2023 19:01:47 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2887249.1703781175.1@sss.pgh.pa.us>
Date: Thu, 28 Dec 2023 11:32:55 -0500
Message-ID: <2887250.1703781175@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2887250.1703781175%40sss.pgh.pa.us>
Precedence: bulk

Richard Guo <guofenglinux@gmail.com> writes:
> I've looked into it a bit.  The problem lies in how the SJE code handles
> the transfer of qual clauses from the removed relation to the remaining
> one.

I am definitely starting to think that the SJE patch was not ready
for prime time.  We keep finding not only minor but major problems
in it --- I'd call this one a "major" one.  Is it time to revert
and rethink it from scratch?

> If we determine that avoiding duplicates is necessary,  I think at least
> we should compare the entire RestrictInfos not just their clauses.  One
> challenge with this approach is that the 'rinfo_serial' usually differs,
> making direct comparison problematic.  I'm wondering if we can make
> 'rinfo_serial' equal_ignore.  Not too sure about that.

I'd say that that will break the cases rinfo_serial was introduced for.
Now, I certainly don't love rinfo_serial and would be happier if we
could do without it, but getting rid of it is another research project.

			regards, tom lane