Re: [PATCH] ternary reloption type

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Nikolay Shaplov <dhyan(at)nataraj(dot)su>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Chris Travers <chris(dot)travers(at)gmail(dot)com>, Timur Magomedov <t(dot)magomedov(at)postgrespro(dot)ru>
Subject: Re: [PATCH] ternary reloption type
Date: 2026-01-16 21:52:59
Message-ID: aWqzOzaWf19oJVQw@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kirill Reshke 2026-01-16 21:57:00 Re: [PATCH] Remove redundant Assert() calls in report_namespace_conflict()
Previous Message Tomas Vondra 2026-01-16 21:29:47 Re: failed NUMA pages inquiry status: Operation not permitted