Re: suggest to rename enable_incrementalsort

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