On Wed, Mar 26, 2025 at 10:17 AM David G. Johnston <david.g.johns...@gmail.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
