Re: pgsql: Add vacuum_truncate configuration parameter.

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Nathan Bossart <nathan(at)postgresql(dot)org>, "pgsql-committers(at)lists(dot)postgresql(dot)org" <pgsql-committers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgsql: Add vacuum_truncate configuration parameter.
Date: 2025-03-20 15:39:53
Message-ID: CAKFQuwbA6-fXn6w5mS_k5_UOS67+0ogt_FyjpbXFnQaAPm98bA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On Thursday, March 20, 2025, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Nathan Bossart <nathan(at)postgresql(dot)org> writes:
> > Since there's presently no way to determine whether a Boolean
> > storage parameter is explicitly set or has just picked up the
> > default value, this commit also introduces an isset_offset member
> > to relopt_parse_elt.
>
> Uh, what? Why is it a good idea to distinguish those states?
> Seems like that risks some very surprising behavior, ie if the
> default is "true", why shouldn't that act exactly like an
> explicit setting of "true"?
>

In order to implement what amounts to coalesce(…) for settings (use global
value unless the table value overrides) one needs a sentinel value that
means unset because settings cannot take on the null value. There is no
such possible sentinel value for boolean so another field is required. The
hazards of choosing Boolean instead of text for settings.

David J.

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Nathan Bossart 2025-03-20 16:09:46 pgsql: Add test for pg_upgrade file transfer modes.
Previous Message Tom Lane 2025-03-20 15:30:54 Re: pgsql: Add vacuum_truncate configuration parameter.