Re: [HACKERS] Vote needed: revert beta2 changes or not?
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 [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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 [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Vote needed: revert beta2 changes or not?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alvaro Herrera Sent: 07 October 2005 03:32 To: Marc G. Fournier Cc: [EMAIL PROTECTED]; 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, [EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Vote needed: revert beta2 changes or not?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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, [EMAIL PROTECTED] 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 -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | 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... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Vote needed: revert beta2 changes or not?
On Friday 07 October 2005 03:50, Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Vote needed: revert beta2 changes or not?
-Original Message- From: Robert Treat [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 6: explain analyze is your friend
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? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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 [EMAIL PROTECTED]To: Tom Lane [EMAIL PROTECTED] g cc: Dave Page dpage@vale-housing.co.uk, Robert Treat Sent by:[EMAIL PROTECTED], pgsql-hackers@postgresql.org, (bcc: Anjali [EMAIL PROTECTED] Sinha/INFOCOMM/RIL) tgresql.orgSubject: 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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 [EMAIL PROTECTED]: 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/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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. -- ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Vote needed: revert beta2 changes or not?
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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 [EMAIL PROTECTED] A good speech is like a good dress that's short enough to be interesting and long enough to cover the subject ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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, [EMAIL PROTECTED] 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 [EMAIL PROTECTED]To: Tom Lane [EMAIL PROTECTED] g cc: Dave Page dpage@vale-housing.co.uk, Robert Treat Sent by:[EMAIL PROTECTED], pgsql-hackers@postgresql.org, (bcc: Anjali [EMAIL PROTECTED] Sinha/INFOCOMM/RIL) tgresql.orgSubject: 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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 ---(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
Re: [HACKERS] Vote needed: revert beta2 changes or not?
Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Vote needed: revert beta2 changes or not?
You're absolutely right of course... /D -Original Message- From: Andreas Pflug[EMAIL PROTECTED] Sent: 07/10/05 18:49:49 To: Dave Pagedpage@vale-housing.co.uk Cc: pgsql-hackers@postgresql.orgpgsql-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
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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 -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | 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... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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. -- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Vote needed: revert beta2 changes or not?
On Thu, 6 Oct 2005, [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Vote needed: revert beta2 changes or not?
-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 [EMAIL PROTECTED] PGP Key: 0x14964AC8 200510062202 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFDRdenvJuQZxSWSsgRAniyAJ9hjJBYdGl1PttvZm1VrfR+vPnI1wCeMW/t u8dv1J8fD4ayUUEFSkhPNrY= =brzE -END PGP SIGNATURE- ---(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
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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 [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Vote needed: revert beta2 changes or not?
[EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Vote needed: revert beta2 changes or not?
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/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
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, [EMAIL PROTECTED] 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
Re: [HACKERS] Vote needed: revert beta2 changes or not?
Just my two cents... but I prefer option 1. 2005/10/6, Alvaro Herrera [EMAIL PROTECTED]: On Thu, Oct 06, 2005 at 10:57:33PM -0300, Marc G. Fournier wrote: On Thu, 6 Oct 2005, [EMAIL PROTECTED] 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/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
