From: | "Rod Taylor" <rbt(at)zort(dot)ca> |
---|---|
To: | <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: pg_dump DROP commands and implicit search paths |
Date: | 2002-05-13 23:42:27 |
Message-ID: | 061e01c1fad7$d7aee300$0f02000a@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> set search_path = my_schema;
> This works fine unless the object name duplicates a system object;
> in that case, since the effective search path is really "pg_catalog,
> my_schema", the DROP will find and try to drop the system object.
I must have missed that day. Why is that exactly? Clients like psql
should probably explicitly specify pg_catalog path anyway.
Afterall, if you create a my_schema.pg_class table (for whatever
reason), and used my search path as my_schema, I'd expect my own to be
hit with my queries. Likewise, postgresql internals should specifiy
the specific namespace -- which they generally do through knowledge of
the pg_class oid.
Is this a temporary thing to tide clients over for a release without
breaking too much?
> 1. Explicitly qualify target-object names in the DROP commands,
> ie, we'd emit
Anyway, question at hand. How about a modification of #1. If the
table begins in 'pg_' explicitly name it my_schema.pg_????. If users
are creating stuff in pg_catalog they should be ready for weird
things -- especially given the 'overriding' state it takes in the
search path.
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2002-05-14 00:31:31 | Re: TRUNCATE |
Previous Message | Lamar Owen | 2002-05-13 23:05:55 | Discontent with development process (was:Re: pgaccess - the discussion is over) |