> -----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
> > > [mailtogsql-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.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

"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

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

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/

---------------------------(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

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

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

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"

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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

---------------------------(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

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend