Re: vacuum_truncate configuration parameter and isset_offset

On Wed, Mar 26, 2025 at 10:17 AM David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> The argument being made is that the enum patch adheres to established practices; and when adding new code that new code is encouraged to adhere to how existing code is written. A vote to keep to such guidelines seems reasonable and sufficient; and can outweigh quite a bit of deficiency such existing code may have relative to the new proposal. The burden is on the new code to justify why it should violate established conventions.

I kind of agree with that, but:

1. We're talking about a minor deviation resulting in a very small
amount of additional code. It's entirely unclear to me why anyone
thinks this is a big deal either way, even if one accepts that the
patch is "wrong", which I don't.

2. While it is true that reloptions have up until not had any case
where the default value wasn't representable by the underlying data
type, but there's a lot of PostgreSQL code and there is ample
precedent across the broader code base for either (a) using a second
Boolean to track whether a first Boolean is set or (b) converting a
Boolean to a three-valued enum. There are many examples of both
styles.

3. It seems like the fact that this has not been needed up until now
is partly just good luck. It's probably true that most integer or
real-valued reloptions can use 0 or -1 for this purpose, strings can
probably mostly use the empty string, and enums can add a value just
for this purpose. But I can't see any intrinsic reason why every
reloption anyone ever adds in the future has to work out nicely in
that way. I feel like you're trying to take an accidental property of
the status quo ante and elevating it to a rule that doesn't seem to
have clearly been intended and wouldn't be a particularly sound design
principle anyway.

--
Robert Haas
EDB: http://www.enterprisedb.com