From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
Cc: | mark(at)mark(dot)mielke(dot)cc, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Vote needed: revert beta2 changes or not? |
Date: | 2005-10-07 02:32:12 |
Message-ID: | 20051007023212.GB10488@surnet.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 06, 2005 at 10:57:33PM -0300, Marc G. Fournier wrote:
> On Thu, 6 Oct 2005, mark(at)mark(dot)mielke(dot)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?
My vote is to not change them again.
> >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.
--
Alvaro Herrera Architect, http://www.EnterpriseDB.com
"La fuerza no está en los medios físicos
sino que reside en una voluntad indomable" (Gandhi)
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-10-07 02:38:54 | Re: [HACKERS] Patching dblink.c to avoid warning about open transaction |
Previous Message | Tom Lane | 2005-10-07 02:28:38 | Re: slower merge join on sorted data chosen over nested loop |