В письме от понедельник, 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
signature.asc
Description: This is a digitally signed message part.
