Dave Page wrote:
The reason it happen that way was because we already had the code as a
contrib-style module for pgAdmin. It was posted because we recognised
that it was becoming a PITA for pgAdmin users to compile a new
server-side component and the functions seemed like they would be useful
Bruce Momjian wrote:
Dave Page wrote:
The reason it happen that way was because we already had the code as a
contrib-style module for pgAdmin. It was posted because we recognised
that it was becoming a PITA for pgAdmin users to compile a new
server-side component and the functions seemed
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 24 June 2005 14:00
To: Dave Page
Cc: PostgreSQL-development; Andreas Pflug
Subject: Re: Server instrumentation patch
Well, I see Marc replying that dbsize should be moved completely from
contrib:
Andreas Pflug wrote:
For the second, please supply a patch that moves _all_ of dbsize into
the main server. I think we have agreement on that.
I don't think so. As I mentioned, those views are broken. Do you want them
to be in core anyway?
Why is e.g. this one broken:
int8
-Original Message-
From: Michael Paesold [mailto:[EMAIL PROTECTED]
Sent: 24 June 2005 16:48
To: Andreas Pflug
Cc: Dave Page; PostgreSQL-development
Subject: Re: [HACKERS] Server instrumentation patch
Andreas Pflug wrote:
For the second, please supply a patch that moves
Michael Paesold wrote:
Andreas Pflug wrote:
For the second, please supply a patch that moves _all_ of dbsize into
the main server. I think we have agreement on that.
I don't think so. As I mentioned, those views are broken. Do you want
them to be in core anyway?
Why is e.g. this one
On Fri, Jun 24, 2005 at 05:10:15PM +0100, Dave Page wrote:
You have pg_database_size(oid) and database_size(name). Afaict, the
latter is equivalent to:
SELECT pg_database_size((SELECT oid FROM pg_database WHERE datname =
'foo'))
My main concern is that the names are inconsistent for no
Andreas Pflug wrote:
Michael Paesold wrote:
Andreas Pflug wrote:
For the second, please supply a patch that moves _all_ of dbsize into
the main server. I think we have agreement on that.
I don't think so. As I mentioned, those views are broken. Do you want
them to be in core anyway?
Dave Page wrote:
You have pg_database_size(oid) and database_size(name). Afaict, the
latter is equivalent to:
SELECT pg_database_size((SELECT oid FROM pg_database WHERE datname =
'foo'))
The typing is even more e.g. for tables or indexes, though. Of course you
can use the raw form, but why
Dave Page wrote:
I vote for all (possibly corrected) functions to be moved into core.
You have pg_database_size(oid) and database_size(name). Afaict, the
latter is equivalent to:
SELECT pg_database_size((SELECT oid FROM pg_database WHERE datname =
'foo'))
My main concern is that the
Dave Page wrote:
The current version of the patch only moves those functions he wants.
Marc says he wants them all moved, and I agree.
OK - did you see Andreas' response to why he hadn't done that (it was
actually posted in response to your original query, not Marcs)? In a
nutshell, the
-Original Message-
From: Michael Paesold [mailto:[EMAIL PROTECTED]
Sent: 24 June 2005 17:53
To: Dave Page; Andreas Pflug
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Server instrumentation patch
My main concern is that the names are inconsistent for no obvious
reason
Dave Page wrote:
-Original Message-
From: Michael Paesold [mailto:[EMAIL PROTECTED]
Sent: 24 June 2005 17:53
To: Dave Page; Andreas Pflug
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Server instrumentation patch
My main concern is that the names
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 24 June 2005 18:47
To: Dave Page
Cc: PostgreSQL-development; Andreas Pflug
Subject: Re: [HACKERS] Server instrumentation patch
The security issue is that we didn't want the backend to be able to
read/write
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 21 June 2005 18:06
To: Dave Page
Cc: PostgreSQL-development; Andreas Pflug
Subject: Server instrumentation patch
OK, let me address this, but you might not like what I have
to say. ;-)
Basically,
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 22 June 2005 04:08
To: Andreas Pflug
Cc: Dave Page; PostgreSQL-development
Subject: Re: Server instrumentation patch
The move of dbsize into the backend is similar. He moves
the parts of
dbsize the
Bruce Momjian wrote:
Dave Page wrote:
Basically, Andreas' approach for 8.0 was to develop a patch (without
posting a proposal or interface), and then argue why pgadmin needs it,
but without addressing the real concerns about the patch.
Extending the logging was to get a means of reading the
Andreas Pflug wrote:
Bruce Momjian wrote:
Dave Page wrote:
Basically, Andreas' approach for 8.0 was to develop a patch (without
posting a proposal or interface), and then argue why pgadmin needs it,
but without addressing the real concerns about the patch.
Extending the logging was
On Tue, 21 Jun 2005, Bruce Momjian wrote:
I am not aware they were all addressed, and if you had terminate in
there, which was clearly not addressed, I question whether the others
issues are addressed too. I think we need to re-discuss the idea of
these functions.
Just curious, but if 'all
19 matches
Mail list logo
