Re: suggest to rename enable_incrementalsort
От | Tomas Vondra |
---|---|
Тема | Re: suggest to rename enable_incrementalsort |
Дата | |
Msg-id | 20200622143114.suqf2korqpydbxxf@development обсуждение исходный текст |
Ответ на | Re: suggest to rename enable_incrementalsort (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: suggest to rename enable_incrementalsort
|
Список | pgsql-hackers |
On Mon, Jun 22, 2020 at 10:16:54AM -0400, Robert Haas wrote: >On Sun, Jun 21, 2020 at 7:22 AM Tomas Vondra ><tomas.vondra@2ndquadrant.com> wrote: >> The reason why I kept the single-word variant is consistency with other >> GUCs that affect planning, like enable_indexscan, enable_hashjoin and >> many others. > >Right, so that makes sense, but from a larger point of view, how much >sense does it actually make? I mean, I get the argument from tradition >and from internal naming consistency, but from a user perspective, why >does it makes sense for there to be underscores between some of the >words and not others? I think it just feels random, like someone is >charging us $1 per underscore so we're economizing. > Sure. I'm not particularly attached to the current GUC, I've only tried to explain that the naming was not entirely random. I agree having an extra _ in the name would make it more readable. >So I'm +1 for changing this, and I'd definitely be +1 for renaming the >others if they weren't released already, and at least +0.5 for it >anyhow. It's bad enough that our source code has names_like_this and >NamesLikeThis and namesLikeThis; when we also start adding >names_likethis and NamesLike_this and maybe NaMeS___LiKeTh_is, I kind >of lose my mind. And avoiding that sort of thing in user-facing stuff >seems even more important. > OK, challenge accepted. $100 to the first person who commits a patch with a variable NaMeS___LiKeTh_is. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: