Re: [HACKERS] Minor DROP TABLESPACE issue

2004-06-19 Thread Tom Lane
Gaetano Mendola <[EMAIL PROTECTED]> writes: > is there no dependencies between these two objects. No, and there's little point in adding one, since it wouldn't prevent the problem from happening if you issue the DROP TABLESPACE from a different database. regards, tom lane

Re: [HACKERS] Minor DROP TABLESPACE issue

2004-06-19 Thread Gaetano Mendola
Tom Lane wrote: Although DROP TABLESPACE can detect tables existing in the target tablespace, it doesn't have any way to detect schemas that reference that tablespace as their default tablespace. Thus you can get implementation-level failures like this one: $ mkdir /tmp/junk regression=# create ta

Re: [HACKERS] Minor DROP TABLESPACE issue

2004-06-18 Thread Tom Lane
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: >> ERROR: tablespace 292909 has been deleted > How about "schema default tablespace 292909 has been deleted"? Yeah, I was wondering if we could finger the specific schema that was causing the problem, but the place that would detect the error co

Re: [HACKERS] Minor DROP TABLESPACE issue

2004-06-18 Thread Christopher Kings-Lynne
ERROR: tablespace 292909 has been deleted How about "schema default tablespace 292909 has been deleted"? Chris ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROT

Re: [HACKERS] Minor DROP TABLESPACE issue

2004-06-18 Thread Gavin Sherry
On Fri, 18 Jun 2004, Tom Lane wrote: > Gavin Sherry <[EMAIL PROTECTED]> writes: > > If we just wanted to make the error message more user friendly, perhaps we > > could *gulp* store the tablespace name in PG_VERSION. > > That's actually not a bad idea from a debugging standpoint. But I don't > se

Re: [HACKERS] Minor DROP TABLESPACE issue

2004-06-18 Thread Tom Lane
Gavin Sherry <[EMAIL PROTECTED]> writes: > If we just wanted to make the error message more user friendly, perhaps we > could *gulp* store the tablespace name in PG_VERSION. That's actually not a bad idea from a debugging standpoint. But I don't see that it helps any for this particular problem.

Re: [HACKERS] Minor DROP TABLESPACE issue

2004-06-18 Thread Gavin Sherry
On Fri, 18 Jun 2004, Tom Lane wrote: > Gavin Sherry <[EMAIL PROTECTED]> writes: > > Is it really that bad? NamespaceCreate() could just touch a file at > > pg_tablespaces/// and > > RemoveSchema() could remove it. > > No, because that wouldn't be rollback-safe. You'd have to make the > placeholde

Re: [HACKERS] Minor DROP TABLESPACE issue

2004-06-18 Thread Tom Lane
Gavin Sherry <[EMAIL PROTECTED]> writes: > Is it really that bad? NamespaceCreate() could just touch a file at > pg_tablespaces/// and > RemoveSchema() could remove it. No, because that wouldn't be rollback-safe. You'd have to make the placeholder file act enough like a real relation that the smg

Re: [HACKERS] Minor DROP TABLESPACE issue

2004-06-18 Thread Gavin Sherry
On Fri, 18 Jun 2004, Tom Lane wrote: > Although DROP TABLESPACE can detect tables existing in the target > tablespace, it doesn't have any way to detect schemas that reference > that tablespace as their default tablespace. Thus you can get > implementation-level failures like this one: > Of cour