Re: [PATCH] ternary reloption type

On 16.01.2026 18:14, Álvaro Herrera wrote:
> I took a quick look at 0001+0002 and I think it's quite reasonable.
> Here it is again with some minor fixups.

Good. I like ternary -> pg_ternary change. That is reasonable. And
postgres.h is better place for it then c.h.

> (I'm omitting the further
> patches for now, we can rebase them later.)

I've rebased the rest of patches, and the whole patchset is in the
attachment.

> I'm CCing Nathan as committer of the vacuum_truncate_set stuff which
> Nikolay so strongly disliked. Any objections to going with this
> approach?

Ok, will quote him and reply below in the this letter.

> > 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.
Ternary option, with it's third optional option is quite complex.

I'd rather not bother postgres developer with this complexity if they
just want to add pure boolean option.

> >+ 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.
If you look at buffering option for example, you will see it does not
behave as pure boolean option.
"auto" value can be explicitly set by user.

Error reporting is not strong part of my patch, I would agree with that.

What if we give two different error reports in two different cases:

Give boolean-like error report when option does not have explicit alias
for third option, and more verbose
error message, listing all available options in the case when third
option have explicit alias?

like

"invalid value for boolean option \"%s\": %s",

and

"invalid value for option \"%s\": %s",
"valid values are 'on', 'off' and '%s'"

we may actually say nothing about option being ternary here