Re: Vote needed: revert beta2 changes or not? - Mailing list pgsql-hackers

I don't get a vote - but I do want to suggest, as a user, that I get
generally annoyed with the presence of interfaces with names that
were chosen for historical reasons, but are maintained only for
compatibility, and either never did, or no longer apply.

I'd rather you left it fixed. Returning it to the old name, for the
sake of process, and no other good reason, doesn't appeal to me. It is
a lesson learned. We move on. Enforce the process next time. Self
inflicted punishment is somewhat masochistic. :-)

Cheers,
mark



On Thu, Oct 06, 2005 at 09:27:55PM -0400, 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.
> 
> Opinions please?
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
> 

-- 
mark@mielke.cc / markm@ncf.ca / markm@nortel.com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada
 One ring to rule them all, one ring to find them, one ring to bring them all                      and in the darkness
bindthem...
 
                          http://mark.mielke.cc/