Re: suggest to rename enable_incrementalsort
От | Tom Lane |
---|---|
Тема | Re: suggest to rename enable_incrementalsort |
Дата | |
Msg-id | 2037457.1592836877@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: suggest to rename enable_incrementalsort (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: suggest to rename enable_incrementalsort
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > 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? Maybe I'm just used to the names, but I find that things like "enable_seqscan" and "enable_nestloop" are pretty readable. Once they get longer, though, not so much. So I agree with renaming enable_incrementalsort. > 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. Nah. Those names are way too well entrenched. Besides which, if we open them up for reconsideration, there's going to be a lot of bikeshedding done. Should "enable_seqscan" become "enable_seq_scan", or "enable_sequential_scan", or maybe "enable_scan_sequential"? Why doesn't "enable_nestloop" contain the word "join"? Etc etc. (I do have to wonder if maybe this one should be enable_sort_incremental.) regards, tom lane
В списке pgsql-hackers по дате отправления: