Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
| От | Tom Lane |
|---|---|
| Тема | Re: Uh, I change my mind about commit_delay + commit_siblings (sort of) |
| Дата | |
| Msg-id | 1608.1340910006@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Uh, I change my mind about commit_delay + commit_siblings (sort of) (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: Uh, I change my mind about commit_delay +
commit_siblings (sort of)
|
| Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jun 28, 2012 at 2:18 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
>> You think it will confuse users less if we start telling them to use
>> something that we have a very long history of telling them not to use?
> I don't buy this line of reasoning at all. If we're going to rename
> the GUC, it should be for accuracy, not PR value. If we start
> renaming something every time we improve it, we're going to go nuts.
> We improved lots of things in 9.2; they didn't all get renamed.
See VACUUM FULL for a recent counterexample --- we basically jacked it
up and drove a new implementation underneath, but we didn't change the
name, despite the fact that we were obsoleting a whole lot more folk
knowledge than exists around commit_delay.
Of course, there were application-compatibility reasons not to rename
that command, which wouldn't apply so much to commit_delay. But still,
we have precedent for expecting that we can fix external documentation
rather than trying to code around whatever it says.
regards, tom lane
В списке pgsql-hackers по дате отправления: