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
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.
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
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
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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
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
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
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
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
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
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
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
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
Bruce Momjian wrote:
bump major library version number?
Were there any incompatible interface changes?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 4: Have you searched our list archives?
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
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:
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
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
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
/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 -
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
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
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
Joshua D. Drake [EMAIL PROTECTED] 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
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] 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
Andrew Dunstan [EMAIL PROTECTED] 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.
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
---(end of broadcast)---
TIP 9: In versions
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
28 matches
Mail list logo
