В письме от понедельник, 24 марта 2025 г. 21:45:27 MSK пользователь Nathan
Bossart написал:
> * We'd need to decide what to say on the documentation side. My first
> instinct is that we should just leave it as "boolean" because otherwise
> we're going to describe something that sounds an awful lot like a
> Boolean.
I think that "boolean-like" is a good word for describing it.
> * I don't think this matches the parse_bool() behavior exactly. For
> example, parse_bool() appears to accept inputs like "t" to mean "true".
> This is also probably not a huge deal.
That was me, who added Enum Reloption to the postgres code, and it was Alvaro
(if I recall correctly) who improved StdRdOptIndexCleanupValues option list to
it's current state. I would trust him here, since, if I recall correctly he is
original author of reloptions the way we know them.
But if "t" is really missing I think we can patch both
StdRdOptIndexCleanupValues and StdRdOptBoolValues to have "t". But in separate
commit.
Moreover if this Boolean-Based enum is a common case, we can think about
adding some basic template, that can be extended by adding "auto" value, or
not-set value and so on. But I do not think that two cases makes it common
case.
> That being said, I'm open to applying this patch if it seems like a
> majority of folks prefer this implementation. FWIW I'm still partial to
> the isset_offset approach for the reasons I've already discussed.
I am for a long while working with reloptions, and can say, that almost nobody
fully understand the idea, how it work and how it was designed. So I would
suggest follow Alvaro, since he is keeper of that knowledge.
And second general idea: changing engine is bad, at least when you can manage
without changing it. We can, your patch proves it.
--
Nikolay Shaplov aka Nataraj
Fuzzing Engineer at Postgres Professional
Matrix IM: @dhyan:nataraj.su
