Re: pg_dump DROP commands and implicit search paths - Mailing list pgsql-hackers

From Rod Taylor
Subject Re: pg_dump DROP commands and implicit search paths
Date
Msg-id 002e01c1fae3$ea7941e0$8001a8c0@jester
Whole thread Raw
In response to pg_dump DROP commands and implicit search paths  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_dump DROP commands and implicit search paths  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> No, it's a necessary thing to comply with the SQL standard.
> The standard thinks all the predefined names are keywords and
> should override user names.  Therefore there *must* be a mode

Hmm.. I'm not fond of this part of the standard in this case -- though
it's got to be there for good reason.

I think I understand the problem better, which may have an easy
solution.  Based on the assumption a DROP SCHEMA statement will also
be issued.

If pg_dump issues a DROP of all user objects at the top, as per user
request, does it really need to issue a DROP of all the objects?

If you DROP the schema, all of the objects contained within the schema
will go with it.  So technically you don't need to drop types, tables,
functions which belong to a given schema.  You just drop that schema.

So we're left with public and pg_catalog.  How about using a qualified
name in all cases of DROP, BUT only issuing drops other than drop
schema schema for public and pg_catalog contents?

Perhaps public could be treated like any other schema as well -- which
really only leaves pg_catalog or no problem since thats what will be
hit by default.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dump DROP commands and implicit search paths
Next
From: Tom Lane
Date:
Subject: Re: pg_dump DROP commands and implicit search paths