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.
--
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
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
-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
-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
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
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,
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
-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
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
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
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
: [HACKERS]
Vote needed: revert beta2 changes or not?
Importance: Normal Sender's OU:
Reliance |--|
| [ ] Confidential |
10/07
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
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
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
-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
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.
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
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
/INFOCOMM/RIL)
tgresql.orgSubject: Re: [HACKERS]
Vote needed: revert beta2 changes or not?
Importance: Normal Sender's OU:
Reliance
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?
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
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
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
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
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
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
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
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
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()
-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
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(),
[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
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 -
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
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
37 matches
Mail list logo
