On 2025-Mar-26, David G. Johnston 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 think the goal of unifying the various pieces of code that handle
options by building a generic "engine" is a good one, and I tend to
agree with the argument that the less things this "engine" has to
support (while keeping the functionality the same), the better. Given
that we've gone far and long without needing the "isset" flag, and that
it's not clear that we really need the concept, I'd rather go with not
having it.
Now -- Nikolay also appears to be saying that we either choose the
concept of a "default" or the concept of the "isset" flag, but not both.
That says to me that the other option would be to remove all default
values and rely solely on isset. Is that a workable option? If it's
not, then it would be clear to me that we'd rather stick with defaults.
But if it is, and if that would get us to an overall simplification of
the concepts, then perhaps that is better. (In other words: for the
other enums that are currently imitating booleans, can we remove that
and instead use isset? And are there other uses of default values that
aren't booleans that can be turned into isset or into something
different?)
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Las navajas y los monos deben estar siempre distantes" (Germán Poo)
