Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> [ shrug... ] The name is not going to change again. I have never cared
> >> for the practice of writing strlen("foo") as if it were a compile-time
> >> constant.
>
> > I think with gcc strlen("foo") is a compile
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> [ shrug... ] The name is not going to change again. I have never cared
>> for the practice of writing strlen("foo") as if it were a compile-time
>> constant.
> I think with gcc strlen("foo") is a compile-time constant.
Portability i
On Tue, 6 Jul 2004, Bruce Momjian wrote:
> Tom Lane wrote:
> > Andreas Pflug <[EMAIL PROTECTED]> writes:
> > > Joe Conway wrote:
> > >> 2) This allocation size was a bit ambigous and I think based on a once
> > >> longer tablespace directory name:
> >
> > > This size calculation originated (copy/p
Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> writes:
> > Joe Conway wrote:
> >> 2) This allocation size was a bit ambigous and I think based on a once
> >> longer tablespace directory name:
>
> > This size calculation originated (copy/paste) from
> > commands/tablespace.c,
>
> Yeah --- B
Joe Conway wrote:
Tom Lane wrote:
[ shrug... ] The name is not going to change again. I have never cared
for the practice of writing strlen("foo") as if it were a compile-time
constant. But certainly it would be entirely pointless to define such a
macro and then use it in only one place.
Fair en
Tom Lane wrote:
[ shrug... ] The name is not going to change again. I have never cared
for the practice of writing strlen("foo") as if it were a compile-time
constant. But certainly it would be entirely pointless to define such a
macro and then use it in only one place.
Fair enough. If there are
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Joe Conway wrote:
>> 2) This allocation size was a bit ambigous and I think based on a once
>> longer tablespace directory name:
> This size calculation originated (copy/paste) from
> commands/tablespace.c,
Yeah --- Bruce did not adjust the string len
Joe Conway wrote:
Attached is the patch I plan to apply. There are a couple of changes
from what was posted.
1) You must have meant tablespace instead of namespace here:
+
+
pg_tablespace_databases(namespace_oid)
+ setof
Andreas Pflug wrote:
From an idea of Bruce, the attached patch implements the function
pg_tablespace_databases(oid) RETURNS SETOF oid
which delivers as set of database oids having objects in the selected
tablespace, enabling an admin to examine only the databases affecting
the tablespace for obje
Andreas Pflug wrote:
From an idea of Bruce, the attached patch implements the function
pg_tablespace_databases(oid) RETURNS SETOF oid
which delivers as set of database oids having objects in the selected
tablespace, enabling an admin to examine only the databases affecting
the tablespace for obje
Joe Conway wrote:
If there are no objections, I'll review and apply this tonight (west
coast USA time).
Andreas, please provide a corresponding documentation patch.
Here we are.
Since I don't have a SGML build environment, syntax is not checked.
Regards,
Andreas
Index: func.sgml
=
Andreas Pflug wrote:
From an idea of Bruce, the attached patch implements the function
pg_tablespace_databases(oid) RETURNS SETOF oid
which delivers as set of database oids having objects in the selected
tablespace, enabling an admin to examine only the databases affecting
the tablespace for obje
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Pflug
> Sent: 28 June 2004 12:25
> To: PostgreSQL Patches
> Subject: [PATCHES] pg_tablespace_databases
>
> From an idea of Bruce, the attached patch
From an idea of Bruce, the attached patch implements the function
pg_tablespace_databases(oid) RETURNS SETOF oid
which delivers as set of database oids having objects in the selected
tablespace, enabling an admin to examine only the databases affecting
the tablespace for objects instead of scanni
14 matches
Mail list logo