Re: pg_dump DROP commands and implicit search paths

From: "Rod Taylor" <rbt(at)zort(dot)ca>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Hackers List" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump DROP commands and implicit search paths
Date: 2002-05-14 01:08:53
Message-ID: 002e01c1fae3$ea7941e0$8001a8c0@jester
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-05-14 01:24:20 Re: pg_dump DROP commands and implicit search paths
Previous Message Tom Lane 2002-05-14 00:42:47 Re: pg_dump DROP commands and implicit search paths