On Thu, 6 Oct 2005, Tom Lane wrote:
> Just before 8.1beta2 went out, Neil made the following changes:
>
> Rename pg_complete_relation_size() to
> pg_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 success or
> failure.
>
> (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 compatibility break 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.
I vote for this one, else we are setting a precedent that this sort of
thing during a beta freeze is acceptable, which it shouldn't be :(
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664