Re: Vote needed: revert beta2 changes or not?

> -----Original Message-----
> From: Robert Treat [mailto:xzilla(at)users(dot)sourceforge(dot)net]
> Sent: 07 October 2005 16:36
> To: pgsql-hackers(at)postgresql(dot)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(at)postgresql(dot)org
> > > [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
> > > Sent: 07 October 2005 02:28
> > > To: pgsql-hackers(at)postgresql(dot)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(at)vale-housing(dot)co(dot)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(at)vale-housing(dot)co(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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)

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(at)sss(dot)pgh(dot)pa(dot)us>:
> "Dave Page" <dpage(at)vale-housing(dot)co(dot)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(at)vale-housing(dot)co(dot)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.
--

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(dot)dharshi(at)telus(dot)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(at)vale-housing(dot)co(dot)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(at)hub(dot)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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

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(at)pervasive(dot)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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664