Thread: Open items list for 8.1

Open items list for 8.1

From
Bruce Momjian
Date:
Here are the open items for 8.1:

                              PostgreSQL 8.1 Open Items                              =========================

Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems or
from http://www.postgresql.org/developer/beta.

Changes
-------
Win32 signal handling patch (Magnus)
fix pg_dump --clean for roles
cosider O_SYNC as default when O_DIRECT exists
test terminate_backend()?
/contrib move to pgfoundry
bump major library version number?
foreign trigger timing issue
pgindent
make sure bitmap scan optimizer settings are reasonable
fix ALTER SCHEMA RENAME for sequence dependency, or remove feature
spinlock performance
fix semantic issues of granted permissions in roles
fix pgxs for Win32 paths

Documentation
-------------
document control over partial page writes

Fixed Since Last Beta
---------------------


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


Re: Open items list for 8.1

From
"Joshua D. Drake"
Date:
> /contrib move to pgfoundry

Is this actually happening?

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


Re: Open items list for 8.1

From
Bruce Momjian
Date:
Joshua D. Drake wrote:
> 
> > /contrib move to pgfoundry
> 
> Is this actually happening?

Josh has talked about it, but not sure where he is.

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


Re: Open items list for 8.1

From
"Joshua D. Drake"
Date:
Bruce Momjian wrote:
> Joshua D. Drake wrote:
> 
>>>/contrib move to pgfoundry
>>
>>Is this actually happening?
> 
> 
> Josh has talked about it, but not sure where he is.

Well pgFoundry isn't ready to have a load of code that is
that actively maintained put on it. It still needs to be moved to
its new servers.

Also we should probably seriously consider which contrib modules
get moved.

IMHO shipping PostgreSQL without TSearch2 and pgcrypto (of course I 
think those should be core anyway) is a non-starter.

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/


Re: Open items list for 8.1

From
Bruce Momjian
Date:
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > Joshua D. Drake wrote:
> > 
> >>>/contrib move to pgfoundry
> >>
> >>Is this actually happening?
> > 
> > 
> > Josh has talked about it, but not sure where he is.
> 
> Well pgFoundry isn't ready to have a load of code that is
> that actively maintained put on it. It still needs to be moved to
> its new servers.
> 
> Also we should probably seriously consider which contrib modules
> get moved.
> 
> IMHO shipping PostgreSQL without TSearch2 and pgcrypto (of course I 
> think those should be core anyway) is a non-starter.

Agreed.  The idea was to move _some_ /contrib to pgfoundry.

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


Re: Open items list for 8.1

From
Tom Lane
Date:
"Joshua D. Drake" <jd@commandprompt.com> writes:
>>> /contrib move to pgfoundry

> Well pgFoundry isn't ready to have a load of code that is
> that actively maintained put on it. It still needs to be moved to
> its new servers.

The modules proposed to be moved out aren't actively maintained now;
if they were we'd probably be keeping them in core.

> Also we should probably seriously consider which contrib modules
> get moved.

You seem to have forgotten the discussion entirely.  These are
the modules proposed to be moved:
adddependdbasedbmirrorfulltextindexmSQL-interfacemacoracletips
        regards, tom lane


Re: Open items list for 8.1

From
Tom Lane
Date:
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> The modules proposed to be moved out aren't actively maintained now;
>> if they were we'd probably be keeping them in core.

> Speaking as a pgFoundry admin, I would say if they aren't actively 
> maintained we don't want them either. pgFoundry is not a dumping ground 
> for modules that are dying.

I didn't say they were dying --- the ones we thought were dead, we
already dropped.  I was responding to Joshua's concern that they might
get enough update traffic to pose a noticeable load on the pgfoundry
server.  Most of them seem to have been touched only once or twice in
the past year.  That does not indicate that they don't have user
communities, though.

There was already very extensive discussion about this in this thread:
http://archives.postgresql.org/pgsql-hackers/2005-06/msg00302.php
and no one objected to the summary proposal I posted here:
http://archives.postgresql.org/pgsql-hackers/2005-06/msg00976.php
so I'm not inclined to think that the floor is still open for debate
about what to move.  It's just a matter of someone getting it done.
        regards, tom lane


Re: Open items list for 8.1

From
Andrew Dunstan
Date:

Tom Lane wrote:

>"Joshua D. Drake" <jd@commandprompt.com> writes:
>  
>
>>>>/contrib move to pgfoundry
>>>>        
>>>>
>
>  
>
>>Well pgFoundry isn't ready to have a load of code that is
>>that actively maintained put on it. It still needs to be moved to
>>its new servers.
>>    
>>
>
>The modules proposed to be moved out aren't actively maintained now;
>if they were we'd probably be keeping them in core.
>
>  
>

Speaking as a pgFoundry admin, I would say if they aren't actively 
maintained we don't want them either. pgFoundry is not a dumping ground 
for modules that are dying. If they are not maintained then drop them. 
They can always be recovered from the CVS archive.

cheers

andrew


Re: Open items list for 8.1

From
"Magnus Hagander"
Date:
> Changes
> -------
> Win32 signal handling patch (Magnus)

Unless someone else steps up to doing this one, please remove it from
the list. I will not have time to dig into this patch before 8.1.

//Magnus


Re: Open items list for 8.1

From
Andrew Dunstan
Date:

Tom Lane wrote:

>>Speaking as a pgFoundry admin, I would say if they aren't actively 
>>maintained we don't want them either. pgFoundry is not a dumping ground 
>>for modules that are dying.
>>    
>>
>
>I didn't say they were dying --- the ones we thought were dead, we
>already dropped.  I was responding to Joshua's concern that they might
>get enough update traffic to pose a noticeable load on the pgfoundry
>server.  Most of them seem to have been touched only once or twice in
>the past year.  That does not indicate that they don't have user
>communities, though.
>
>
>  
>

OK. I agree that we do not need to wait, any more than we are waiting 
now on other newly registered projects. What we do need is an owner in 
each case.

cheers

andrew


Re: Open items list for 8.1

From
Bruce Momjian
Date:
Magnus Hagander wrote:
> > Changes
> > -------
> > Win32 signal handling patch (Magnus)
> 
> Unless someone else steps up to doing this one, please remove it from
> the list. I will not have time to dig into this patch before 8.1.

OK, what should the TODO item be?

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


Re: Open items list for 8.1

From
"Magnus Hagander"
Date:
> > > Changes
> > > -------
> > > Win32 signal handling patch (Magnus)
> >
> > Unless someone else steps up to doing this one, please
> remove it from
> > the list. I will not have time to dig into this patch before 8.1.
>
> OK, what should the TODO item be?

A link to the mail should be there, I guess (it's somewhere in the
archives). "Investigate different way of handling signals on win32" with
a link perhaps.

Note - we need to investigate, I'm not convinced that doing it is worth
it at all (I asked for opinions on that earlier, but no other win32
hacker was available for comment). And then if it is, the patch itself
should be reviewed.

//Magnus


Re: Open items list for 8.1

From
Bruce Momjian
Date:
Magnus Hagander wrote:
> > > > Changes
> > > > -------
> > > > Win32 signal handling patch (Magnus)
> > > 
> > > Unless someone else steps up to doing this one, please 
> > remove it from 
> > > the list. I will not have time to dig into this patch before 8.1.
> > 
> > OK, what should the TODO item be?
> 
> A link to the mail should be there, I guess (it's somewhere in the
> archives). "Investigate different way of handling signals on win32" with
> a link perhaps.
> 
> Note - we need to investigate, I'm not convinced that doing it is worth
> it at all (I asked for opinions on that earlier, but no other win32
> hacker was available for comment). And then if it is, the patch itself
> should be reviewed.

Added to TODO:
       o Improve signal handling,            http://archives.postgresql.org/pgsql-patches/2005-06/msg00027.php

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


Re: Open items list for 8.1

From
Bruce Momjian
Date:
The open items list has been reduced nicely:
                              PostgreSQL 8.1 Open Items                              =========================

Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems or
from http://www.postgresql.org/developer/beta.

Changes
-------
fix pg_dump --clean for roles
foreign trigger timing issue
fix ALTER SCHEMA RENAME for sequence dependency, or remove feature
spinlock performance
fix semantic issues of granted permissions in roles
fix pgxs for Win32 paths

Questions
---------
cosider O_SYNC as default when O_DIRECT exists
/contrib move to pgfoundry
bump major library version number?
pgindent, when?
make sure bitmap scan optimizer settings are reasonable

Documentation
-------------
document control over partial page writes

Fixed Since Last Beta
---------------------




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


Re: Open items list for 8.1

From
Peter Eisentraut
Date:
Bruce Momjian wrote:
> bump major library version number?

Were there any incompatible interface changes?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


Re: Open items list for 8.1

From
Bruce Momjian
Date:
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > bump major library version number?
> 
> Were there any incompatible interface changes?

No, I don't _think_ so, but we have been bitten by this before, not
because of API change but because of use of libpgport functions  called
by libpq in one release but not in a later one.  What happened was that
apps pulled pgport functions from libpq and not from libpgport, and when
the calls were removed from libpq, the old apps didn't work anymore. 
This hit us in 8.0.X.

Makefile.global has this now:
# Force clients to pull symbols from the non-shared library libpgport# rather than pulling some libpgport symbols from
libpqjust because# libpq uses those functions too.  This makes applications less# dependent on changes in libpq's usage
ofpgport.  To do this we link to# pgport before libpq.  This does cause duplicate -lpgport's to appear# on client link
lines.ifdefPGXSlibpq_pgport = -L$(libdir) -lpgport $(libpq)elselibpq_pgport = -L$(top_builddir)/src/port -lpgport
$(libpq)endif

so I think we are OK going forward, but it something I wanted to keep an
eye out for.  In older releases we actually had reports of failures, and
just told people to recompile, not realizing the magnitude of the
problem (it was assume to be more old CVS build issue than a
backward-compatible issue.)  I am going to remove the open item about
this because I think if we had a problem, we would have heard about it
by now.

It is an interesting story because it does highlight that the libpq API
is not the only cause of a major bump.


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


Re: Open items list for 8.1

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> fix ALTER SCHEMA RENAME for sequence dependency, or remove feature

I've posted a proposed patch to fix this.  The patch requires an initdb
(to add new sequence functions), so if we do that we may as well also
fix the 32/64bit risk mentioned here:
http://archives.postgresql.org/pgsql-hackers/2005-09/msg01241.php

Also, the floor seems open to discuss whether or not to revert the file
access functions to their pre-beta2 APIs.  I've got mixed feelings about
that myself, but you can certainly make a case that the current
definitions are not enough cleaner than what was there before to justify
changing.  This seems particularly true for pg_cancel_backend(), which
already was in the core in 8.0.
        regards, tom lane


Re: Open items list for 8.1

From
"Marc G. Fournier"
Date:
On Tue, 27 Sep 2005, Tom Lane wrote:

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> fix ALTER SCHEMA RENAME for sequence dependency, or remove feature
>
> I've posted a proposed patch to fix this.  The patch requires an initdb
> (to add new sequence functions), so if we do that we may as well also
> fix the 32/64bit risk mentioned here:
> http://archives.postgresql.org/pgsql-hackers/2005-09/msg01241.php
>
> Also, the floor seems open to discuss whether or not to revert the file
> access functions to their pre-beta2 APIs.  I've got mixed feelings about
> that myself, but you can certainly make a case that the current
> definitions are not enough cleaner than what was there before to justify
> changing.  This seems particularly true for pg_cancel_backend(), which
> already was in the core in 8.0.

IMHO, changes like this *should not* have been allowed during beta, period 
... even during feature freeze, it would have been questionable :(

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


Re: Open items list for 8.1

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > fix ALTER SCHEMA RENAME for sequence dependency, or remove feature
> 
> I've posted a proposed patch to fix this.  The patch requires an initdb
> (to add new sequence functions), so if we do that we may as well also
> fix the 32/64bit risk mentioned here:
> http://archives.postgresql.org/pgsql-hackers/2005-09/msg01241.php
> 
> Also, the floor seems open to discuss whether or not to revert the file
> access functions to their pre-beta2 APIs.  I've got mixed feelings about
> that myself, but you can certainly make a case that the current
> definitions are not enough cleaner than what was there before to justify
> changing.  This seems particularly true for pg_cancel_backend(), which
> already was in the core in 8.0.

I am thinking we should keep things as they are now.  

I remember two changes of significance.  First, pg_cancel_backend()'s
return value was change to boolean.  I think the compelling argument
here is that we are adding other functions that _should_ return boolean,
and to keep pg_cancel_backend() as 1/0 was kind of strange.  Also, I
assume pg_cancel_backend() is not a general use function and therefore
is more of an admin function that we can adjust as needed to improve the
API.  We have always allowed rare/admin functions to be improved without
as much concern for backward compatibility as a more mainstream feature.

The other change was the rename of pg_complete_relation_size() to
pg_total_relation_size().  While there was a huge (exhausting)
discussion that finalized on pg_complete_relation_size(), a number of
people felt pg_total_relation_size() was better.

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


Re: Open items list for 8.1

From
"Dave Page"
Date:

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Marc
> G. Fournier
> Sent: 28 September 2005 00:50
> To: Tom Lane
> Cc: Bruce Momjian; PostgreSQL-development; Neil Conway
> Subject: Re: [HACKERS] Open items list for 8.1
>
>
> IMHO, changes like this *should not* have been allowed during
> beta, period
> ... even during feature freeze, it would have been questionable :(

Agreed. It's not like they weren't discussed to death prior to then as
well.

Whilst I'm not so wed to the changes to the others, pg_cancel_backend()
should certainly not be changed on whim - I know for a fact there are
people for whom this will cause problems.

Regards, Dave


Re: Open items list for 8.1

From
"Marc G. Fournier"
Date:
On Tue, 27 Sep 2005, Bruce Momjian wrote:

> Tom Lane wrote:
>> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>>> fix ALTER SCHEMA RENAME for sequence dependency, or remove feature
>>
>> I've posted a proposed patch to fix this.  The patch requires an initdb
>> (to add new sequence functions), so if we do that we may as well also
>> fix the 32/64bit risk mentioned here:
>> http://archives.postgresql.org/pgsql-hackers/2005-09/msg01241.php
>>
>> Also, the floor seems open to discuss whether or not to revert the file
>> access functions to their pre-beta2 APIs.  I've got mixed feelings about
>> that myself, but you can certainly make a case that the current
>> definitions are not enough cleaner than what was there before to justify
>> changing.  This seems particularly true for pg_cancel_backend(), which
>> already was in the core in 8.0.
>
> I am thinking we should keep things as they are now.

The problem isn't whether or not they should be changed, the problem is 
that they were changed *during* beta AND *against* the direction that 
discussion on these changes went ... pre-beta would have been more 
acceptable, but pre-feature freeze would have been much preferred ... but 
*post-beta*, this should never have happened unless it created a critical 
bug, which I have seen no arguments that it did ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


Re: Open items list for 8.1

From
Neil Conway
Date:
On Wed, 2005-28-09 at 18:35 -0300, Marc G. Fournier wrote:
> The problem isn't whether or not they should be changed, the problem is 
> that they were changed *during* beta AND *against* the direction that 
> discussion on these changes went

I'm not sure what you mean: what is "the direction that discusson on
these changes went"? (If you're referring to "complete" vs. "total",
that hardly constitutes a change in direction.)

> ... pre-beta would have been more acceptable, but pre-feature freeze
> would have been much preferred

I think there is an argument to be made for reverting pg_cancel_backend,
since that function was released with 8.0. Personally I'm sceptical that
there are very many people using that function in scripts (particularly
using it in such a way that their scripts will break if the return type
is changed). Since we've already made the change, I don't really see the
point in reverting it, but I don't mind if someone wants to do it.

As for the other changes, I think there is absolutely no reason to
revert them. Since when is making changes to the signatures of new
functions forbidden during the beta period? AFAIK we don't make
guarantees of backward compatibility during the beta period, nor would
it be sensible to do so. We had the opportunity to fix some poor API
choices, and since an initdb was already required I think making these
changes for beta2 was quite reasonable.

-Neil




Re: Open items list for 8.1

From
Bruce Momjian
Date:
Marc G. Fournier wrote:
> On Tue, 27 Sep 2005, Bruce Momjian wrote:
> 
> > Tom Lane wrote:
> >> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >>> fix ALTER SCHEMA RENAME for sequence dependency, or remove feature
> >>
> >> I've posted a proposed patch to fix this.  The patch requires an initdb
> >> (to add new sequence functions), so if we do that we may as well also
> >> fix the 32/64bit risk mentioned here:
> >> http://archives.postgresql.org/pgsql-hackers/2005-09/msg01241.php
> >>
> >> Also, the floor seems open to discuss whether or not to revert the file
> >> access functions to their pre-beta2 APIs.  I've got mixed feelings about
> >> that myself, but you can certainly make a case that the current
> >> definitions are not enough cleaner than what was there before to justify
> >> changing.  This seems particularly true for pg_cancel_backend(), which
> >> already was in the core in 8.0.
> >
> > I am thinking we should keep things as they are now.
> 
> The problem isn't whether or not they should be changed, the problem is 
> that they were changed *during* beta AND *against* the direction that 
> discussion on these changes went ... pre-beta would have been more 
> acceptable, but pre-feature freeze would have been much preferred ... but 
> *post-beta*, this should never have happened unless it created a critical 
> bug, which I have seen no arguments that it did ...

It was done quickly to complete it for beta2.  Neil talked to Tom and me
about it before he made the change. Obviously we all guessed wrong on
this one.

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


Re: Open items list for 8.1

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> It was done quickly to complete it for beta2.  Neil talked to Tom and me
> about it before he made the change. Obviously we all guessed wrong on
> this one.

Personally I had forgotten that pg_cancel_backend was in the previous
release and so there was a backwards-compatibility issue to consider.
There's no doubt that a boolean return value is cleaner than an int
return value, but we don't ordinarily make non-backward-compatible
changes just because they're cleaner.  Comparable case: timeofday()
is still returning text not timestamptz after all these years, even
though that is *obviously* the wrong API, and even though we could
probably change it without a huge risk of breaking things.

As for the total-vs-complete function name business, I do personally
like "total" better, but the time to have been making that argument was
back during the original discussion, which itself went on way too long.
Renaming it now with relatively little discussion was definitely a
violation of our normal development process.  I'll take my fair share
of the blame for this, because I encouraged Neil to do it without
stopping to think that the names had already been hashed over
extensively.  But it was the wrong way to proceed.

In short, yeah, I think we should revert.
        regards, tom lane


Re: Open items list for 8.1

From
"Jim C. Nasby"
Date:
On Wed, Sep 28, 2005 at 06:07:02PM -0400, Neil Conway wrote:
> On Wed, 2005-28-09 at 18:35 -0300, Marc G. Fournier wrote:
> > The problem isn't whether or not they should be changed, the problem is 
> > that they were changed *during* beta AND *against* the direction that 
> > discussion on these changes went
> 
> I'm not sure what you mean: what is "the direction that discusson on
> these changes went"? (If you're referring to "complete" vs. "total",
> that hardly constitutes a change in direction.)
> 
> > ... pre-beta would have been more acceptable, but pre-feature freeze
> > would have been much preferred
> 
> I think there is an argument to be made for reverting pg_cancel_backend,
> since that function was released with 8.0. Personally I'm sceptical that
> there are very many people using that function in scripts (particularly
> using it in such a way that their scripts will break if the return type
> is changed). Since we've already made the change, I don't really see the
> point in reverting it, but I don't mind if someone wants to do it.

I think it's just as important to work towards keeping interfaces clean
as it is not to break old code.

What's wrong with adding pg_cancel_backend(...) RETURNS int as an alias
for the one that returns boolean, and document that it's deprecated and
will be removed in the future.

The same goes for Tom's timeofday() RETURNS text example.

> As for the other changes, I think there is absolutely no reason to
> revert them. Since when is making changes to the signatures of new
> functions forbidden during the beta period? AFAIK we don't make
> guarantees of backward compatibility during the beta period, nor would
> it be sensible to do so. We had the opportunity to fix some poor API
> choices, and since an initdb was already required I think making these
> changes for beta2 was quite reasonable.

Agreed. Not making API changes now means we get to live with them for
years and years.
-- 
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


Re: Open items list for 8.1

From
Neil Conway
Date:
On Fri, 2005-30-09 at 17:47 -0500, Jim C. Nasby wrote:
> What's wrong with adding pg_cancel_backend(...) RETURNS int as an alias
> for the one that returns boolean, and document that it's deprecated and
> will be removed in the future.

You can't overload functions based on their return type alone.

-Neil




Re: Open items list for 8.1

From
Bruce Momjian
Date:
Jim C. Nasby wrote:
> On Wed, Sep 28, 2005 at 06:07:02PM -0400, Neil Conway wrote:
> > On Wed, 2005-28-09 at 18:35 -0300, Marc G. Fournier wrote:
> > > The problem isn't whether or not they should be changed, the problem is 
> > > that they were changed *during* beta AND *against* the direction that 
> > > discussion on these changes went
> > 
> > I'm not sure what you mean: what is "the direction that discusson on
> > these changes went"? (If you're referring to "complete" vs. "total",
> > that hardly constitutes a change in direction.)
> > 
> > > ... pre-beta would have been more acceptable, but pre-feature freeze
> > > would have been much preferred
> > 
> > I think there is an argument to be made for reverting pg_cancel_backend,
> > since that function was released with 8.0. Personally I'm sceptical that
> > there are very many people using that function in scripts (particularly
> > using it in such a way that their scripts will break if the return type
> > is changed). Since we've already made the change, I don't really see the
> > point in reverting it, but I don't mind if someone wants to do it.
> 
> I think it's just as important to work towards keeping interfaces clean
> as it is not to break old code.
> 
> What's wrong with adding pg_cancel_backend(...) RETURNS int as an alias
> for the one that returns boolean, and document that it's deprecated and
> will be removed in the future.
> 
> The same goes for Tom's timeofday() RETURNS text example.

We don't have the ability to have to functions that take the same
parameters and return different results because there is no facility to
decide which function to call based on what return value is expected,
because a simple query doesn't have a return value restriction:
SELECT pg_cancel_backend();

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


Re: Open items list for 8.1

From
"Jim C. Nasby"
Date:
On Fri, Sep 30, 2005 at 06:58:05PM -0400, Bruce Momjian wrote:
> We don't have the ability to have to functions that take the same
> parameters and return different results because there is no facility to
> decide which function to call based on what return value is expected,
> because a simple query doesn't have a return value restriction:
> 
>     SELECT pg_cancel_backend();

Duh, I keep forgetting that.
-- 
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