From: Tom Lane <tgl@sss.pgh.pa.us>
To: Christophe Pettus <xof@thebuild.com>
cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: = TRUE vs IS TRUE confuses partition index creation
In-reply-to: <8864BFAA-81FD-4BF9-8E06-7DEB8D4164ED@thebuild.com>
References: <8864BFAA-81FD-4BF9-8E06-7DEB8D4164ED@thebuild.com>
Comments: In-reply-to Christophe Pettus <xof@thebuild.com>
	message dated "Tue, 16 Aug 2022 14:33:51 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1551757.1660687056.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 16 Aug 2022 17:57:36 -0400
Message-ID: <1551758.1660687056@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1551758.1660687056%40sss.pgh.pa.us>
Precedence: bulk

Christophe Pettus <xof@thebuild.com> writes:
> When an index is created on the root of a (declarative) partitioned tabl=
e, that index is also created on the children, unless there is an existing=
 index on that child that matches the definition of the new index.  It see=
ms that using `=3D TRUE` confuses it, compared to `IS TRUE`.

IIRC, "b =3D true" will be simplified to just "b" somewhere in expression
preprocessing.  I'm betting that something in the partitioned index
matching code is applying that preprocessing to one index predicate and
not the other, whereupon they look different.  If that's the explanation,
there are likely other cases that should match and fail to.

			regards, tom lane