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)
