Re: suggest to rename enable_incrementalsort
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-06-22T14:16:54Z
Lists: pgsql-hackers
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. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Rename enable_incrementalsort for clarity
- e61225ffab3f 14.0 landed
- 94e454cddfba 13.0 landed