Also, the change to pg_cancel_backend breaks backwards
compatibility
with 8.0, which is a whole lot worse than breaking it with
8.1-beta1.
Unfortunately, core doesn't see this as backward
compatibility break,
instead it's regarded as adjustment of a new function.
Anything
Also, the change to pg_cancel_backend breaks backwards
compatibility
with 8.0, which is a whole lot worse than breaking it with
8.1-beta1.
Yeah, I thought about that (and Bruce and I already discussed
it offlist before I committed the changes). The function was
newly added in 8.0
Marc G. Fournier [EMAIL PROTECTED] writes:
Is there a reason the old/new can't be aliaseed to each other, instead of
the old just being removed?
Any change like that would require another initdb. If we were going to
force another initdb, my vote would be to revert these functions to
where
Is there a reason the old/new can't be aliaseed to each
other, instead
of the old just being removed?
Any change like that would require another initdb. If we
were going to force another initdb, my vote would be to
revert these functions to where they were in beta1. It was a
On Mon, 19 Sep 2005, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Is there a reason the old/new can't be aliaseed to each other, instead of
the old just being removed?
Any change like that would require another initdb. If we were going to
force another initdb, my vote would be
-hackers@postgresql.org
Subject: Re: [HACKERS] Beta2 Wrap Up ...
+1 on reverting them back then ... and on
a quick beta3 (ie. by end of week?)
+1 from me as well.
/D
-Unmodified Original Message-
On Mon, 19 Sep 2005, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes
On Mon, 2005-19-09 at 10:57 -0400, Tom Lane wrote:
Any change like that would require another initdb. If we were going to
force another initdb, my vote would be to revert these functions to
where they were in beta1.
What purpose would that serve? About the only thing purpose I can see is
to
On Sun, 18 Sep 2005, Magnus Hagander wrote:
Having spent days, no, weeks deciding on that name on list I do not
want to see it change this late, especially as we'll now need to go
and update pgAdmin again!
Fortunately, pgAdmin doesn't use that function, but only the
basic pg_relation_size().
I thought we'd more or less dropped that idea based on Andreas'
responses.
I've heard no argument against renaming
pg_complete_relation_size() to
pg_total_relation_size()
Having spent days, no, weeks deciding on that name on list I
do not want to see it change this late,
Magnus Hagander wrote:
I thought we'd more or less dropped that idea based on Andreas'
responses.
I've heard no argument against renaming
pg_complete_relation_size() to
pg_total_relation_size()
Having spent days, no, weeks deciding on that name on list I
do not want to see it change
Having spent days, no, weeks deciding on that name on list I do not
want to see it change this late, especially as we'll now need to go
and update pgAdmin again!
Fortunately, pgAdmin doesn't use that function, but only the
basic pg_relation_size(). Phew!
Good for you :-)
Also, the
On Sat, 2005-17-09 at 14:47 +0200, Magnus Hagander wrote:
Also, the change to pg_cancel_backend breaks backwards compatibility
with 8.0, which is a whole lot worse than breaking it with 8.1-beta1.
Yeah, I thought about that (and Bruce and I already discussed it offlist
before I committed the
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Conway
Sent: 16 September 2005 03:48
To: Tom Lane
Cc: Marc G. Fournier; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Beta2 Wrap Up ...
On Thu, 2005-15-09 at 22:31 -0400, Tom Lane
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Conway
Sent: 16 September 2005 06:38
To: Marc G. Fournier
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Beta2 Wrap Up ...
On Thu, 2005-15-09 at 22:06 -0400, Neil Conway wrote
On Fri, 2005-16-09 at 08:47 +0100, Dave Page wrote:
Perhaps you could allow 24 hours before committing potentially
controversial changes in future?
My apologies for the rush -- I normally would wait longer for a
consensus. In fact, I _was_ waiting for a consensus until I saw that the
wrap for
-Original Message-
From: Neil Conway [mailto:[EMAIL PROTECTED]
Sent: 16 September 2005 14:57
To: Dave Page
Cc: Marc G. Fournier; pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] Beta2 Wrap Up ...
On Fri, 2005-16-09 at 08:47 +0100, Dave Page wrote:
Perhaps you could allow
Tomorrow afternoon, we are planning on packaging up Beta2 .. if anyone is
sitting on something that should get in before that happens, or has a bug
they are sitting on, please let us know ...
I am planning on wrapping things at around noon my time (~3pm GMT, I
believe, if I have my
On Thu, 2005-15-09 at 21:09 -0300, Marc G. Fournier wrote:
Tomorrow afternoon, we are planning on packaging up Beta2 .. if anyone is
sitting on something that should get in before that happens, or has a bug
they are sitting on, please let us know ...
One change that I would like to get into
Neil Conway [EMAIL PROTECTED] writes:
One change that I would like to get into beta2 is the proposed
refactoring of some of the new system info / administration functions.
I thought we'd more or less dropped that idea based on Andreas'
responses.
regards, tom lane
On Thu, 2005-15-09 at 22:31 -0400, Tom Lane wrote:
I thought we'd more or less dropped that idea based on Andreas'
responses.
I've heard no argument against renaming pg_complete_relation_size() to
pg_total_relation_size() and changing the functions that return an
integer status code to make
On Thu, 2005-15-09 at 22:06 -0400, Neil Conway wrote:
One change that I would like to get into beta2 is the proposed
refactoring of some of the new system info / administration functions.
Ok, this is done: the changes have been committed to CVS HEAD and the
catalog version number has been
21 matches
Mail list logo
