Not that I want this to become a flame war - but because two separate
people challenged my opinion, and I only wish to clarify what it is... :-)
On Thu, Oct 06, 2005 at 10:32:12PM -0400, Alvaro Herrera wrote:
> On Thu, Oct 06, 2005 at 10:57:33PM -0300, Marc G. Fournier wrote:
> > On Thu, 6 Oct 2005, mark@mark.mielke.cc wrote:
> > >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's not just for the sake of process. It's because the pgAdmin guys,
> who were the ones which invented the API and the users of it, are
> already using it with this interface. Changing it means they take the
> compatibility hit. However, I question how hard the compatibility hit
> is -- for the return type, isn't it a matter of testing two possible
> values instead of one? The naming case is harder, but how much?
If it is to be changed in the future, say, 8.2, I don't believe this
point has merit. If, however, it would not be changed in the future,
say, 8.2, you are correct.
> > >It is
> > >a lesson learned. We move on. Enforce the process next time. Self
> > >inflicted punishment is somewhat masochistic. :-)
> > If we don't enforce the process this time, why would we enforce it next
> > time?
> Because we will know better.
Yes. And because the people involved are not children. They are mature
adults. :-)
Cheers,
mark
--
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/