Re: pg_dump DROP commands and implicit search paths

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.

In response to

Responses

Browse pgsql-hackers by date

  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)