Thread: Re: pgsql-server: Tablespaces.

(Moved to -hackers)

> Log Message:
> -----------
> Tablespaces.  Alternate database locations are dead, long live tablespaces.

Sweet :)

> There are various things left to do: contrib dbsize and oid2name modules
> need work, and so does the documentation.  Also someone should think about
> COMMENT ON TABLESPACE and maybe RENAME TABLESPACE.  Also initlocation is
> dead, it just doesn't know it yet.

Comment on TABLESPACE is impossible, no?  Tablespaces are a global 
relation and pg_description isn't.

I'll do RENAME and OWNER TO for tablespaces with this patch I'm working 
on atm if people like.

Chris

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> Comment on TABLESPACE is impossible, no?  Tablespaces are a global 
> relation and pg_description isn't.

Well, it has the same issues as COMMENT ON DATABASE, which we support,
though crudely.

Perhaps we should think about creating a shared version of
pg_description so we could have more reasonable support for comments
on shared objects.  I'm not in a hurry for this but it would be a
reasonable TODO item.
        regards, tom lane

Tom Lane wrote:

>Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
>  
>
>>Comment on TABLESPACE is impossible, no?  Tablespaces are a global 
>>relation and pg_description isn't.
>>    
>>
>
>Well, it has the same issues as COMMENT ON DATABASE, which we support,
>though crudely.
>
>Perhaps we should think about creating a shared version of
>pg_description so we could have more reasonable support for comments
>on shared objects.  I'm not in a hurry for this but it would be a
>reasonable TODO item.
>  
>

There are more sharing issues with tablespaces (which are already 
supported in pgadmin3, btw :-)
To drop a tablespace, it must be empty, but it can be quite painful to 
find out which objects are populating it. Currently, every database has 
to be queried for pg_class.reltablespace=<mytablespaceoid>. I'd love to 
show tablespace dependency information, which would require some sort of 
global pg_namespace, pg_class and pg_index.

Any thoughts about this?

Regards,
Andreas

> Well, it has the same issues as COMMENT ON DATABASE, which we support,
> though crudely.
> 
> Perhaps we should think about creating a shared version of
> pg_description so we could have more reasonable support for comments
> on shared objects.  I'm not in a hurry for this but it would be a
> reasonable TODO item.

Just add a comment text column to the databases, users, groups and 
tablespaces tables.  Then special case them in obj_description.

Chris

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
>> Perhaps we should think about creating a shared version of
>> pg_description so we could have more reasonable support for comments
>> on shared objects.  I'm not in a hurry for this but it would be a
>> reasonable TODO item.

> Just add a comment text column to the databases, users, groups and 
> tablespaces tables.  Then special case them in obj_description.

Hm ... seems like that requires more special cases, not fewer.
What I was imagining was the current database-local pg_description plus
a single shared table pg_shared_description.  When you add more kinds of
shared objects (SQL roles maybe?) obj_description doesn't need to
change...
        regards, tom lane

> Hm ... seems like that requires more special cases, not fewer.
> What I was imagining was the current database-local pg_description plus
> a single shared table pg_shared_description.  When you add more kinds of
> shared objects (SQL roles maybe?) obj_description doesn't need to
> change...

Oh yeah, that's a much better idea :) Didn't think of that :)

Chris