Date: Fri, 16 Jan 2026 15:52:59 -0600
From: Nathan Bossart <nathandbossart@gmail.com>
To: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@alvh.no-ip.org>
Cc: Nikolay Shaplov <dhyan@nataraj.su>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
	Chris Travers <chris.travers@gmail.com>,
	Timur Magomedov <t.magomedov@postgrespro.ru>
Subject: Re: [PATCH] ternary reloption type
Message-ID: <aWqzOzaWf19oJVQw@nathan>
References: <4047390.3Lj2Plt8kZ@thinkpad-pgpro>
 <202601161509.54de2afpgxpp@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <202601161509.54de2afpgxpp@alvherre.pgsql>
Archived-At: <https://www.postgresql.org/message-id/aWqzOzaWf19oJVQw%40nathan>
Precedence: bulk

On Fri, Jan 16, 2026 at 04:14:52PM +0100, Álvaro Herrera wrote:
> I'm CCing Nathan as committer of the vacuum_truncate_set stuff which
> Nikolay so strongly disliked.  Any objections to going with this
> approach?

Looks generally reasonable.

> This could also be used for other options such as `vacuum_index_cleanup`
> and `buffering`, but lets get the scaffolding in first.

Part of me wonders if we should just modify the Boolean relopt
implementation instead of using ternary only when needed.

> +				parsed = parse_bool(value, &b);
> +				option->values.ternary_val = b ? TERNARY_TRUE : TERNARY_FALSE;
> +				if (validate && !parsed)
> +					ereport(ERROR,
> +							(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> +							 errmsg("invalid value for ternary option \"%s\": %s",
> +									option->gen->name, value)));

Shouldn't this say "invalid value for boolean option"?  IIUC the intent is
for ternary to be exactly like bool, except it defaults to an "unset" value
that can't be chosen by the user.  In that sense, I think "ternary" is kind
of a misnomer, but I wouldn't count this as an objection.

-- 
nathan