From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
cc: hu_yajun@qq.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18442: Unnecessary Sort operator in indexScan Plan
In-reply-to: 
 <CAApHDvpMwFHTnBLC9zWz9U2Sg61dO6NdjWrf0jvwDHTKv-rudg@mail.gmail.com>
References: <18442-aca4c9134416990e@postgresql.org>
 <2135177.1713535423@sss.pgh.pa.us>
 <CAApHDvpMwFHTnBLC9zWz9U2Sg61dO6NdjWrf0jvwDHTKv-rudg@mail.gmail.com>
Comments: In-reply-to David Rowley <dgrowleyml@gmail.com>
	message dated "Mon, 22 Apr 2024 13:53:02 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2909004.1713752742.1@sss.pgh.pa.us>
Date: Sun, 21 Apr 2024 22:25:42 -0400
Message-ID: <2909005.1713752742@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2909005.1713752742%40sss.pgh.pa.us>
Precedence: bulk

David Rowley <dgrowleyml@gmail.com> writes:
> Couldn't strict equality conditions be handled using the same method
> that we use to handle an Eclass with two distinct Consts. e.g a = 1
> and a=b and b=2?

Perhaps, but it'd be a bit odd and confusing to treat two NULLs as
distinct rather than equal.

On the whole I'm disinclined to add complexity around this.  My gut
says there are more semantic gotchas than this one, and I think the
use-case is at best pretty hokey.  If your data design requires using
NULL as though it's a normal data value, you're in a state of sin
already, and you're going to find SQL fighting you all the way.

(A question closely related to this is whether IS NOT DISTINCT FROM
could be optimized more like regular equality.  I'm not convinced
about the use-case there either, although perhaps it's worth looking
into.)

			regards, tom lane