From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: suggest to rename enable_incrementalsort |
Date: | 2020-06-22 14:16:54 |
Message-ID: | CA+TgmoazhPwebpOwNbHt1vJoos1eLYhJVQPka+pptSLgS685aA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jun 21, 2020 at 7:22 AM Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2020-06-22 14:18:52 | Asymmetry in opening and closing indices for partition routing |
Previous Message | Josef Šimánek | 2020-06-22 13:33:00 | Re: [PATCH] Initial progress reporting for COPY command |