Vote needed: revert beta2 changes or not?
От | Tom Lane |
---|---|
Тема | Vote needed: revert beta2 changes or not? |
Дата | |
Msg-id | 27641.1128648475@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Vote needed: revert beta2 changes or not?
(mark@mark.mielke.cc)
Re: Vote needed: revert beta2 changes or not? (Rod Taylor <pg@rbt.ca>) Re: Vote needed: revert beta2 changes or not? ("Marc G. Fournier" <scrappy@postgresql.org>) Re: Vote needed: revert beta2 changes or not? ("Greg Sabino Mullane" <greg@turnstep.com>) Re: Vote needed: revert beta2 changes or not? (David Fetter <david@fetter.org>) Re: Vote needed: revert beta2 changes or not? (Andreas Pflug <pgadmin@pse-consulting.de>) Re: Vote needed: revert beta2 changes or not? (Simon Riggs <simon@2ndquadrant.com>) Re: Vote needed: revert beta2 changes or not? ("Jim C. Nasby" <jnasby@pervasive.com>) |
Список | pgsql-hackers |
Just before 8.1beta2 went out, Neil made the following changes: Rename pg_complete_relation_size() topg_total_relation_size(), for the sake of brevity and clarity.Make pg_reload_conf(),pg_rotate_logfile(), and pg_cancel_backend()return a boolean rather than an integer to indicate successorfailure. (BTW, this is by no means solely Neil's fault, because both Bruce and I encouraged him to proceed.) Several people have opined that we ought to revert one or both of these changes. The arguments in favor of reversion are basically (a) we failed to follow normal development process. The names and APIs of these functions were already hashed out in long discussions months ago, so second-guessing them with relatively little discussion is at best impolite. (b) pg_cancel_backend() was already in 8.0, and so changing it now represents an API break, for which being "a little cleaner" is not sufficient justification. As against that, changing them back now might just confuse matters even more. And I tend to agree with Neil's judgment that the new definitions are cleaner in themselves. We need to make a decision before releasing beta3. We've already forced an initdb for beta3, so we can change "for free" now, but it's entirely possible that there will be no additional opportunity before 8.1 final. Some private discussion among core didn't result in any clear consensus, so it seems the best thing to do is throw the matter out for a vote on pgsql-hackers. The plausible alternatives seem to be: 1. Leave it as-is. 2. Revert the result type of pg_cancel_backend() to int, but leave the rest as-is (minimum change to avoid a compatibilitybreak with 8.0). 3. Revert all three result-type changes, in the name of consistency. 4. Revert all four changes, on the grounds that we shouldn't allow such a violation of process. Opinions please? regards, tom lane
В списке pgsql-hackers по дате отправления:
Предыдущее
От: "Kevin Grittner"Дата:
Сообщение: slower merge join on sorted data chosen over nested loop