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
