Thread: Vote needed: revert beta2 changes or not?
Just before 8.1beta2 went out, Neil made the following changes:
Rename pg_complete_relation_size() topg_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
successorfailure.
(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
compatibilitybreak 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
bindthem...
http://mark.mielke.cc/
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, Pennsylvania19073
>> >> 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? > > http://www.postgresql.org/docs/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 > 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.
> -----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
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
bindthem...
http://mark.mielke.cc/
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 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? 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.
"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 > both > > int 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, Pennsylvania19073
On 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 > both > > int 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)
Unsubscribe me. Or Can anyone forward me the emailId of the concerned
person..??
Regards,
Anjali Sinha
ASCG, Reliance Infocomm
J Block, SB-11, 2nd Floor,
Dhirubhai Ambani Knowledge City,
Thane Belapur Road, New Mumbai India, 400 709
DID: 91 22 30387862
____________________________________________
Alvaro Herrera
<alvherre@alvh.no-ip.or To: Tom Lane <tgl@sss.pgh.pa.us>
g> cc: Dave Page <dpage@vale-housing.co.uk>, Robert Treat
Sent by: <xzilla@users.sourceforge.net>, pgsql-hackers@postgresql.org, (bcc: Anjali
pgsql-hackers-owner@pos Sinha/INFOCOMM/RIL) tgresql.org Subject:
Re:[HACKERS] Vote needed: revert beta2 changes or not? Importance: Normal
Sender'sOU: Reliance |------------------|
| [ ] Confidential | 10/07/2005 09:38 PM
|------------------|
On 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
> both
>
> int 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)
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
IMHO, it leads to more maintenance work to support backward compatibility. Can we give it a desupport version such as saying, "it's currently deprecated and will be completely removed in 8.2, 8.3, ...?" That way, supporting the both for the short-term wouldn't be too wasteful. ( sorry Tom, GMAIL defaults to REPLY not REPLY ALL :( ) 2005/10/7, Tom Lane <tgl@sss.pgh.pa.us>: > "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 > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > -- Respectfully, Jonah H. Harris, Database Internals Architect EnterpriseDB Corporation http://www.enterprisedb.com/
On Fri, 2005-10-07 at 12:08 -0400, Alvaro Herrera wrote: > On 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 > > both > > > > int pg_cancel_backend(int) > > bool pg_backend_cancel(int) > > > > with the former deprecated but still there for backward compatibility? > > +1 I would vote for this "if" we deprecate the old one and say that it will be removed for 8.2. Sincerely, 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 Fri, 2005-10-07 at 11:56 -0400, 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
> both
>
> int pg_cancel_backend(int)
> bool pg_backend_cancel(int)
>
> with the former deprecated but still there for backward compatibility?
I could vote for:
bool pg_query_cancel(int)
backend_cancel or cancel_backend sounds like it should terminate the
entire backend like kill -TERM would do.
--
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 07 October 2005 16:57 > To: Dave Page > Cc: Robert Treat; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Vote needed: revert beta2 changes or not? > > "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? Oh no, what have I started!! :-) Let's just make the change and let the few people affected modify their scripts, otherwise this is gonna get very messy. Thankfully I think we've all learnt from this :-) Regards, Dave.
Yeah this is a good point, if you say okay folks we will keep this for you
till version 8.2 or whatever and then you are on your own, with major
notices wherever reasonable, manuals et al. then I would throw my vote for
this, given I am entitled to a vote.
ASD.
On Fri, 7 Oct 2005, Jonah H. Harris wrote:
> IMHO, it leads to more maintenance work to support backward
> compatibility. Can we give it a desupport version such as saying,
> "it's currently deprecated and will be completely removed in 8.2, 8.3,
> ...?" That way, supporting the both for the short-term wouldn't be
> too wasteful.
>
> ( sorry Tom, GMAIL defaults to REPLY not REPLY ALL :( )
>
>
--
Aly S.P Dharshi
aly.dharshi@telus.net
"A good speech is like a good dress that's short enough to be interesting and long enough to cover the
subject"
On Fri, 7 Oct 2005, Bruce Momjian wrote: > 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 >> both >> >> int 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. :-) Actually, my only argument *against* the change was that it was during a period where such changes were not supposed to happen ... so I vote in favor of reverting (as Tom suggests above) and then removing pg_cancel_backend altogether for 8.2 ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Fri, 7 Oct 2005, Joshua D. Drake wrote: > On Fri, 2005-10-07 at 12:08 -0400, Alvaro Herrera wrote: >> On 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 >>> both >>> >>> int pg_cancel_backend(int) >>> bool pg_backend_cancel(int) >>> >>> with the former deprecated but still there for backward compatibility? >> >> +1 > > I would vote for this "if" we deprecate the old one and say that it will > be removed for 8.2. Agreed 100% ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
See the bottom of the email that has links to how to unsubscribe from the list .. *all* lists have this appended to the bottom of the emails ... On Fri, 7 Oct 2005, Anjali.Sinha@relianceinfo.com wrote: > Unsubscribe me. Or Can anyone forward me the emailId of the concerned > person..?? > > Regards, > Anjali Sinha > ASCG, Reliance Infocomm > J Block, SB-11, 2nd Floor, > Dhirubhai Ambani Knowledge City, > Thane Belapur Road, New Mumbai India, 400 709 > DID: 91 22 30387862 > ____________________________________________ > > > > Alvaro Herrera > <alvherre@alvh.no-ip.or To: Tom Lane <tgl@sss.pgh.pa.us> > g> cc: Dave Page <dpage@vale-housing.co.uk>, Robert Treat > Sent by: <xzilla@users.sourceforge.net>, pgsql-hackers@postgresql.org, (bcc:Anjali > pgsql-hackers-owner@pos Sinha/INFOCOMM/RIL) > tgresql.org Subject: Re: [HACKERS] Vote needed: revert beta2 changes or not? > Importance: Normal Sender's OU: Reliance |------------------| > | [ ] Confidential | > 10/07/2005 09:38 PM |------------------| > > > > > > > On 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 >> both >> >> int 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) > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Dave Page wrote: > > > Oh no, what have I started!! :-) In order to keep traffic on this list low, both of us should be excluded...;-) Regards, Andreas
> > 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? > > Oh no, what have I started!! :-) > > Let's just make the change and let the few people affected > modify their scripts, otherwise this is gonna get very messy. Yeah. As one who has been bitten when I tested a system on the new version, I still think it's reasonably easy. It's not like queries using pg_cancel_backend are scattered throughout an app. In my case it's in a single place, and it's easy enough to work around it. (My solution: write a tiny wrapper SQL function that looks different when running on 8.0 and 8.1) If we deprecate it and say "gone in 8.2", I'm going to have to write this wrapper anyway. And if we don't set a schedule for when it's gone, we might as well not deprecate it, and that would make it very messy... > Thankfully I think we've all learnt from this :-) Yup, that's the main thing. This time it wasn't too bad (as it only affected a seldom-used function), it might not be next time if we do it again. //Magnus
> > > 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? > > I could vote for: > > bool pg_query_cancel(int) > > backend_cancel or cancel_backend sounds like it should > terminate the entire backend like kill -TERM would do. IIRC, the original discussion had a possible pg_query_cancel(int) functoin that would cancel a query based on XID or something like that, and we wanted to differentiate from that. (No such function was ever created, but it was the reason, IIRC) Note that at this time there was also a pg_backend_terminate(int) that would terminate the backend (in fact, IIRC it's still in the code, but commented out). When both exist, the difference is clear... //Magnus
"Magnus Hagander" <mha@sollentuna.net> writes:
>> I could vote for:
>>
>> bool pg_query_cancel(int)
>>
>> backend_cancel or cancel_backend sounds like it should
>> terminate the entire backend like kill -TERM would do.
> IIRC, the original discussion had a possible pg_query_cancel(int)
> functoin that would cancel a query based on XID or something like that,
> and we wanted to differentiate from that. (No such function was ever
> created, but it was the reason, IIRC)
Right. Rod's suggestion is superficially more logical, but it doesn't
fit into the plans for future extension of the capability.
regards, tom lane
You're absolutely right of course... /D -----Original Message----- From: "Andreas Pflug"<pgadmin@pse-consulting.de> Sent: 07/10/05 18:49:49 To: "Dave Page"<dpage@vale-housing.co.uk> Cc: "pgsql-hackers@postgresql.org"<pgsql-hackers@postgresql.org> Subject: Re: [HACKERS] Vote needed: revert beta2 changes or not? Dave Page wrote: > > > Oh no, what have I started!! :-) In order to keep traffic on this list low, both of us should be excluded...;-) Regards, Andreas -----Unmodified Original Message----- Dave Page wrote: > > > Oh no, what have I started!! :-) In order to keep traffic on this list low, both of us should be excluded...;-) Regards, Andreas
Hello all, In _bt_compare function , instead of calling FunctionCall2 , I want to call FunctionCall3 with three parameter and in btcompare.c "btname_pattern_cmp" function will take three parameter and i want to change this function according to third parameter. But the biggest issue is initdb is also using this index for creating and initializing its own index structure ( may be meta index sorts of ) So how I solve this issue...please guide me... thanx sandeep On Fri, 7 Oct 2005, Dave Page wrote: > You're absolutely right of course... > > /D > -----Original Message----- > From: "Andreas Pflug"<pgadmin@pse-consulting.de> > Sent: 07/10/05 18:49:49 > To: "Dave Page"<dpage@vale-housing.co.uk> > Cc: "pgsql-hackers@postgresql.org"<pgsql-hackers@postgresql.org> > Subject: Re: [HACKERS] Vote needed: revert beta2 changes or not? > > Dave Page wrote: >> >> >> Oh no, what have I started!! :-) > > In order to keep traffic on this list low, both of us should be > excluded...;-) > > Regards, > Andreas > > > > -----Unmodified Original Message----- > Dave Page wrote: >> >> >> Oh no, what have I started!! :-) > > In order to keep traffic on this list low, both of us should be > excluded...;-) > > Regards, > Andreas > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > -- ------------------ | Sandeep Satpal | | M.Tech Student | | Lab 212 KReSIT | ------------------
On Sat, 2005-08-10 at 00:42 +0530, sandeep satpal wrote: > ... please guide me Two suggestions: (1) Don't start new threads by replying to an existing thread of no relevance to the new subject (2) Spend some time phrasing your question in a coherent manner -- you're more likely to get a useful response. Read http://www.catb.org/~esr/faqs/smart-questions.html For example, what is the actual high-level problem you are trying to solve? How are you attempting to solve it, and exactly what difficulties have you encountered in doing so? -Neil
On Thu, 2005-10-06 at 21:27 -0400, Tom Lane wrote: > (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. > 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). Seems like the best way to go, without reading other posts. ISTM one day somebody will want to return an error state other than success/fail from that function and we would end up back here anyway. Best Regards, Simon Riggs
Hello, Sorry for last mail. I hope this time I will explain my doubt more clearly. The _bt_compare function in "nbtree.c" file calls "FunctionCall2" and it passes two arguments , one is the scankey which we want to search on and other key is on current b-tree node. My problem is I want to pass three parameter and the third argument will be used for taking decision during comparision that whether I want case-sensitive comparision or case-insensitive. But "initdb" also uses the same _bt_compare function for creating its own indexes. For eg. when we write /usr/pgsql/bin/initdb -D /usr/local/data And my modification may create problems. How I solve this ?? Hope this time I had explained in more clear way... thanx, -- ------------------ | Sandeep Satpal | | M.Tech Student | | Lab 212 KReSIT | ------------------
On Sat, Oct 08, 2005 at 12:48:50PM +0530, sandeep satpal wrote: > The _bt_compare function in "nbtree.c" file calls "FunctionCall2" and it > passes two arguments , one is the scankey which we want to search on and > other key is on current b-tree node. > > My problem is I want to pass three parameter and the third argument will > be used for taking decision during comparision that whether I want > case-sensitive comparision or case-insensitive. Well, if you want to pass a third argument, go ahead. Just make sure you update all the appropriate function calls. > But "initdb" also uses the same _bt_compare function for creating its own > indexes. > For eg. > when we write /usr/pgsql/bin/initdb -D /usr/local/data > And my modification may create problems. > How I solve this ?? Well, _bt_compare is used for every btree index in the system, including all the system indexes. A fresh initdb already has several dozen indexes already so your code has to deal with that. Remember, _bt_compare compares strings, integers, floats, dates, etc and your code needs to work for all of them too... What does it mean to compare dates case-insensetivly? Hope this helps, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
sandeep satpal wrote: > The _bt_compare function in "nbtree.c" file calls "FunctionCall2" and it > passes two arguments , one is the scankey which we want to search on and > other key is on current b-tree node. > > My problem is I want to pass three parameter and the third argument will > be used for taking decision during comparision that whether I want > case-sensitive comparision or case-insensitive. This is certainly the wrong layer to be making these changes. Have you considered using the citext type? If it doesn't suit you, you could use it as a foundation for developing your own. What you need to change is the function stored in the scankey. -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34 Voy a acabar con todos los humanos / con los humanos yo acabaré voy a acabar con todos / con todos los humanos acabaré (Bender)
On Fri, Oct 07, 2005 at 12:22:14PM -0400, Rod Taylor wrote: > I could vote for: > > bool pg_query_cancel(int) > > backend_cancel or cancel_backend sounds like it should terminate the > entire backend like kill -TERM would do. Agreed. In fact, I thought that's what it actually did. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
While it's important to stick with policies lest they become useless, I think the bigger picture needs to be remembered: the policies are in place to produce good design decisions and to not let the development cycle drag out uncontrollably. In this case, ISTM that there is now a better naming scheme than what was originally discussed, and IMHO it's defeatist to ignore that just because we're in beta. It would absolutely have been better to have changed the names before entering beta, just like it's absolutely better to change the names now rather than after 8.1. I'd vote for officially #1 + depricating the old cancel_backend as of a specific version (ie 8.2 or 8.3). -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Sat, 8 Oct 2005, Jim C. Nasby wrote: > On Fri, Oct 07, 2005 at 12:22:14PM -0400, Rod Taylor wrote: >> I could vote for: >> >> bool pg_query_cancel(int) >> >> backend_cancel or cancel_backend sounds like it should terminate the >> entire backend like kill -TERM would do. > > Agreed. In fact, I thought that's what it actually did. Oh good, I wasn't going to say anything, but that was what I thought it did too :( ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> Well, _bt_compare is used for every btree index in the system, > including all the system indexes. A fresh initdb already has several > dozen indexes already so your code has to deal with that. > > Remember, _bt_compare compares strings, integers, floats, dates, etc > and your code needs to work for all of them too... What does it mean to > compare dates case-insensetivly? Yes, shouldn't you just be making a simple new string type that's case insensitive? Chris