Re: 8.0 beta status - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 8.0 beta status
Date
Msg-id 25964.1091850874@sss.pgh.pa.us
Whole thread Raw
In response to Re: 8.0 beta status  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Responses Re: 8.0 beta status
Re: 8.0 beta status
List pgsql-hackers
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
>> Yeah, those are all bug fixes and okay for post-beta I think.  But which
>> two tablespace failures are you thinking of exactly?  The last couple
>> weeks have been a bit of a blur for me...

>
http://groups.google.com.au/groups?q=tablespaces+group:comp.databases.postgresql.hackers&hl=en&lr=&ie=UTF-8&group=comp.databases.postgresql.hackers&scoring=d&selm=Pine.LNX.4.58.0407281411470.17889%40linuxworld.com.au&rnum=4

Okay, this is a the-error-message-could-be-better gripe.  Fair enough,
but it's not top of my priority list ...

>
http://groups.google.com.au/groups?q=tablespaces+group:comp.databases.postgresql.hackers&hl=en&lr=&ie=UTF-8&group=comp.databases.postgresql.hackers&scoring=d&selm=4107211C.2050508%40familyhealth.com.au&rnum=5

I think the problem here is that we don't have a syntax for saying
"my tablespace is the same as my database's default tablespace" or "my
tablespace is the same as my schema's default tablespace", when there is
an intermediate object (schema or table) that isn't using that
tablespace. (Note that "TABLESPACE pg_default" does definitely not mean
either of these.)

This is fixable with some special syntax but is it worth the trouble?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Vacuum Cost Documentation?
Next
From: Tom Lane
Date:
Subject: Re: PITR - recovery to a particular transaction