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 que
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 tha
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.
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 c
Bruce Momjian 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-compatibi
Marc G. Fournier wrote:
> On Tue, 27 Sep 2005, Bruce Momjian wrote:
>
> > Tom Lane wrote:
> >> Bruce Momjian 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
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
On Tue, 27 Sep 2005, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian 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
fi
> -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.
Tom Lane wrote:
> Bruce Momjian 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 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 me
Bruce Momjian 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
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 rele
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?
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_d
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
> > > 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,
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
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 t
> 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
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.
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 a
"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 t
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 maintai
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 serve
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
/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.comman
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 handli
28 matches
Mail list logo
