From: Nikolay Shaplov <dhyan@nataraj.su>
To: =?UTF-8?B?w4FsdmFybw==?= Herrera <alvherre@alvh.no-ip.org>,
 Peter Eisentraut <peter@eisentraut.org>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Chris Travers <chris.travers@gmail.com>,
 Timur Magomedov <t.magomedov@postgrespro.ru>,
 Nathan Bossart <nathandbossart@gmail.com>
Subject: Re: [PATCH] ternary reloption type
Date: Mon, 17 Aug 2026 17:16:20 +0300
Message-ID: <3425885.aeNJFYEL58@thinkpad-pgpro>
Organization: Postgres Professional
In-Reply-To: <3b230dc4-9495-46b6-8634-e04f9833d45e@eisentraut.org>
References: 
 <202601211907.po3lliqjtvsy@alvherre.pgsql>
 <3b230dc4-9495-46b6-8634-e04f9833d45e@eisentraut.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3432455.44csPzL39Z";
 micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: 
 <https://www.postgresql.org/message-id/3425885.aeNJFYEL58%40thinkpad-pgpro>
Precedence: bulk

--nextPart3432455.44csPzL39Z
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Nikolay Shaplov <dhyan@nataraj.su>
Subject: Re: [PATCH] ternary reloption type
Date: Mon, 17 Aug 2026 17:16:20 +0300
Message-ID: <3425885.aeNJFYEL58@thinkpad-pgpro>
Organization: Postgres Professional
In-Reply-To: <3b230dc4-9495-46b6-8634-e04f9833d45e@eisentraut.org>
MIME-Version: 1.0

=D0=92 =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=B5 =D0=BE=D1=82 =D0=BF=D0=BE=D0=BD=
=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 17 =D0=B0=D0=B2=D0=B3=D1=
=83=D1=81=D1=82=D0=B0 2026=E2=80=AF=D0=B3. 16:03:12 =D0=9C=D0=BE=D1=81=D0=
=BA=D0=B2=D0=B0, =D1=81=D1=82=D0=B0=D0=BD=D0=B4=D0=B0=D1=80=D1=82=D0=BD=D0=
=BE=D0=B5 =D0=B2=D1=80=D0=B5=D0=BC=D1=8F=20
=D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Pe=
ter Eisentraut =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

> > I don't like that pg_ternary was added to postgres.h.=20

That's understandable.

> There are, depending on how you count, a few to many other ternary types
> used throughout the tree, and it's not clear why this one should be the
> standard one now.  At least if so that should have involved some
> discussion and analysis on the other ones.  There are also some
> tradeoffs about how this type should be designed.  This particular one
> uses 0 and 1 for false and true, and -1 for unset.  Others use 0 for
> unset and other values for false and true.  Maybe this choice is useful
> for this particular use, but we shouldn't impose it on everyone.

The idea was that from the reloptions point of view, ternary is a boolean w=
ith=20
one extra possibility. This comes about purely historically, because the=20
current and future ternary options are born from boolean options, so it's=20
convenient to keep the values that encode explicit 'yes' and 'no', so that =
the=20
corresponding fields in the database don't have to be updated when switchin=
g=20
from boolean to ternary. With this encoding, everything will keep working t=
he=20
way it did without any pg_catalog update.

As for the 'third' value, using an enum seemed reasonable in this case, and=
=20
then you have to pick one specific value. If 0 and 1 are already taken, the=
n -1=20
seems like the logical option.
=09
When developing this patch, I wasn't aware of the existence of other ternar=
y-
logic implementations in Postgres. I'm not against bringing these=20
implementations to a common style. But in the case of reloptions, we're=20
constrained by the fact that the data is already stored on disk and it's=20
better not to change it. If the other ternary values are used only in memor=
y,=20
then it might be right to bring them to the same data type as the one used =
in=20
options. If you share a list of the other places where ternary logic is als=
o=20
used, we'll all have a chance to look at it and assess how justified bringi=
ng=20
them to a common style would be.

> Independent of that, I don't understand why this was put into postgres.h
> instead of c.h.  It's not particular to backend code, as far as I can tel=
l.

> I think it would be better to rename this to something like
> relopt_ternary and move it to access/reloptions.h.

If it were up to me, I'd keep the definition of pg_ternary in access/
reloptions.h and not interfere with the core Postgres code. Unfortunately,=
=20
though, one of the ternary options value is located in the StdRdOptions str=
uct=20
defined in include/utils/rel.h, so the pg_ternary type has to be defined in=
 some=20
very global place. Which one exactly is debatable. In the original version =
of=20
the patch I put it in c.h. When committing, =C3=81lvaro moved it to postgre=
s.h. I=20
concluded that =C3=81lvaro knows better where it should be. I don't have an=
 opinion=20
of my own on this question =E2=80=94 the main thing for me is that pg_terna=
ry be=20
defined in a header file that can be included in utils/rel.h.

I guess some logic behind it might be like this: We using pg_ternary name, =
not=20
just ternary, because some other library header might also want to define=20
ternary. And since this type has pg_ suffix postgres.h seems to be better p=
lace=20
to store it, than c.h. pg_ means it is related to postgres. Things from  c.=
h=20
are not postgres related.

> If we want to consolidate all ternary types, that might be useful, but
> it should be an explicit discussion.

I think we want. Me at least. Let's discuss it.

=2D-=20
Nikolay Shaplov aka Nataraj
=46uzzing Engineer at Postgres Professional
Matrix IM: @dhyan:nataraj.su

--nextPart3432455.44csPzL39Z
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEE+sk3ebqQKlezKOi8PMbfuIHAGpgFAmqDF7QACgkQPMbfuIHA
Gpglzgf/RvSv9/Ox40b1kYAGP8CCWf5ggLhpcNsaLcPcdZQkXT7gzNcIGpcOR79y
VTTFQ3pB5fGJ5Lc87AUNtMUoads66tTr8XPZOTIUGIbiKE5PoSU30YkrtCPWc3p2
IzSEUG4eJ+nQcDMfhBa4S6bnOiQgt7H+OWHLCtuZvICIkRPvvGuj4bQ9puL8vZ+0
pLO9MULemxAwjwig/9tUlqlu3tSLE+4xrV/IGAqExmLiS6BvJsoKrJKUaY+Y4foM
FlDzfFDvrUNUtc+yg92HeQvg3TdarlEbm0+BTO0X9Dj59s503KVTFhjEX8BBgWLZ
ygHPT3fumxYDHetDSQYOybdTk60Bmg==
=aHd6
-----END PGP SIGNATURE-----

--nextPart3432455.44csPzL39Z--