"Rod Taylor" <rbt@zort.ca> writes:
> 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.
If you want that behavior, you can set the search path as
"my_schema, pg_catalog". This does not solve pg_dump's DROP
problem, however, since an unqualified reference to say pg_class
might still be taken as an attempt to drop pg_catalog.pg_class.
There's no guarantee that my_schema.pg_class exists beforehand.
> Is this a temporary thing to tide clients over for a release without
> breaking too much?
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
wherein pg_catalog is searched first (but is not the target for
create operations, so path = "pg_catalog, my_schema" is not right
either).
> Anyway, question at hand. How about a modification of #1. If the
> table begins in 'pg_' explicitly name it my_schema.pg_????.
Tables are not really the problem. Think about types, functions,
operators. There's no handy rule to know which names conflict
(or, even more to the point, might conflict a release or two from
now).
I am currently thinking that explicitly setting path = my_schema,
pg_catalog might solve some of the corner cases for pg_dump ... but
it does not fix the DROP problem.
regards, tom lane
