Vote needed: revert beta2 changes or not?
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
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 bind them...
On Thu, 2005-10-06 at 21:27 -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.
The plausible alternatives seem to be:
1. Leave it as-is.
+1
I prefer the changes and if the choice is do it now or do them in 8.2
(they are improvements), then I choose to take them now.
--
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 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?
You either always enforce it, or never ... you don't pick and choose
though ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The plausible alternatives seem to be:
1. Leave it as-is.
I vote for this. It's not an ideal situation, but the names should
be changed at some point - better now than later, as it reduces the
lifetime of the "bad" names. Put a large warning (and a small apology)
in the release notes.
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200510062202
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iD8DBQFDRdenvJuQZxSWSsgRAniyAJ9hjJBYdGl1PttvZm1VrfR+vPnI1wCeMW/t
u8dv1J8fD4ayUUEFSkhPNrY=
=brzE
-----END PGP SIGNATURE-----
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.
+1, for what it's worth.
Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
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 is
a lesson learned. We move on. Enforce the process next time. Self
inflicted punishment is somewhat masochistic. :-)
I agree with this sentiment. It is not like this happens regularly and
we need to punish someone. Mistakes happen in process, but it is
usually not intentional, meaning fear of punishment isn't effective, or
even desirable.
If it happened regularly by a single individual, that would be a
different story.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
1. Leave it as-is.
+1 From here..
Joshua D. Drake
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
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?
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)
Just my two cents... but I prefer option 1.
2005/10/6, Alvaro Herrera <alvherre@alvh.no-ip.org>:
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?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)---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
--
Respectfully,
Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
http://www.enterprisedb.com/
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane
Sent: 07 October 2005 02:28
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] Vote needed: revert beta2 changes or not?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).
+1 (I do know people who will need to modify scripts because of this
change), though I'm obviously not going to win having already scanned
the entire thread :-)
/D
Import Notes
Resolved by subject fallback
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of
Alvaro Herrera
Sent: 07 October 2005 03:32
To: Marc G. Fournier
Cc: mark@mark.mielke.cc; Tom Lane; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Vote needed: revert beta2 changes or not?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?
Thanks Alvaro :-). More by luck than judgement we actually weren't
affected by any of the changes in the end. I do think that
pg_cancel_backend should be reverted given that it is a change from 8.0
as opposed to being completely new, and I definitely think we need to
ensure that this sort of thing doesn't happen again in beta without very
good reason.
Regards, Dave.
Import Notes
Resolved by subject fallback
Tom Lane wrote:
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.
When talking about cleanliness of the definition, a name like
"pg_stat_file" seems quite unfortunate since in the presence of many
pg_stat_* statistics functions it sounds like a function dealing with
statistics files. The pg_*_file names were actually not discussed
exhaustively, originally posted as pg_file_*.
Taking from this, a clean naming convention would require
pg_backend_cancel (and pg_file_stat), extending this beta2->beta3
changes even more but leaving backward compatibility if the int
pg_cancel_backend isn't replaced, but accompanied by a clean bool version.
As Dave already pointed out, pgAdmin isn't affected itself, since we
need some additional functions anyway to remain 8.0 compatibility.
Regards,
Andreas
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 bind them...
On Friday 07 October 2005 03:50, Dave Page wrote:
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane
Sent: 07 October 2005 02:28
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] Vote needed: revert beta2 changes or not?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).+1 (I do know people who will need to modify scripts because of this
change), though I'm obviously not going to win having already scanned
the entire thread :-)
I'm sympathetic to this, but doesn't it seem worse to have this one function
return int if all the others return boolean? Also they don't need to modify
scripts, can't they just write thier own pg_cacnel_backend to return int
based on the boolean version?
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
-----Original Message-----
From: Robert Treat [mailto:xzilla@users.sourceforge.net]
Sent: 07 October 2005 16:36
To: pgsql-hackers@postgresql.org
Cc: Dave Page; Tom Lane
Subject: Re: [HACKERS] Vote needed: revert beta2 changes or not?On Friday 07 October 2005 03:50, Dave Page wrote:
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane
Sent: 07 October 2005 02:28
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] Vote needed: revert beta2 changes or not?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).+1 (I do know people who will need to modify scripts because of this
change), though I'm obviously not going to win havingalready scanned
the entire thread :-)
I'm sympathetic to this, but doesn't it seem worse to have
this one function
return int if all the others return boolean?
It's not pretty, but then how many other names might we change these
days because they don't fit in with current thinking?
Also they
don't need to modify
scripts, can't they just write thier own pg_cacnel_backend to
return int
based on the boolean version?
No, because you can't overload based purely on return type. I suppose
they could write it to take an int8 pid or something, but that's a hack.
Regards, Dave.
Import Notes
Resolved by subject fallback
"Dave Page" <dpage@vale-housing.co.uk> writes:
Also they
don't need to modify
scripts, can't they just write thier own pg_cacnel_backend to
return int
based on the boolean version?
No, because you can't overload based purely on return type. I suppose
they could write it to take an int8 pid or something, but that's a hack.
Well, how many people want to vote for Andreas' suggestion of having
both
int pg_cancel_backend(int)
bool pg_backend_cancel(int)
with the former deprecated but still there for backward compatibility?
regards, tom lane
Tom Lane wrote:
"Dave Page" <dpage@vale-housing.co.uk> writes:
Also they
don't need to modify
scripts, can't they just write thier own pg_cacnel_backend to
return int
based on the boolean version?No, because you can't overload based purely on return type. I suppose
they could write it to take an int8 pid or something, but that's a hack.Well, how many people want to vote for Andreas' suggestion of having
bothint pg_cancel_backend(int)
bool pg_backend_cancel(int)with the former deprecated but still there for backward compatibility?
-1, too confusing. We have always been willing to modify API's,
especially for admin stuff, as we add features. If we keep everything
around, we end up like Oracle. That has VARCHAR2 written all over it. :-)
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073On Fri, Oct 07, 2005 at 11:56:50AM -0400, Tom Lane wrote:
No, because you can't overload based purely on return type. I suppose
they could write it to take an int8 pid or something, but that's a hack.Well, how many people want to vote for Andreas' suggestion of having
bothint pg_cancel_backend(int)
bool pg_backend_cancel(int)with the former deprecated but still there for backward compatibility?
+1
--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34
"Siempre hay que alimentar a los dioses, aunque la tierra est� seca" (Orual)
