Re: [PATCH] ternary reloption type - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: [PATCH] ternary reloption type
Date
Msg-id aWqzOzaWf19oJVQw@nathan
Whole thread Raw
In response to Re: [PATCH] ternary reloption type  (Álvaro Herrera <alvherre@alvh.no-ip.org>)
List 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



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: failed NUMA pages inquiry status: Operation not permitted
Next
From: Kirill Reshke
Date:
Subject: Re: [PATCH] Remove redundant Assert() calls in report_namespace_conflict()