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

--
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 bind them...

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, Pennsylvania 19073

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

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

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 bind them...

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, 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)

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

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/

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