Re: erroneous restore into pg_catalog schema - Mailing list pgsql-hackers

From Robert Haas
Subject Re: erroneous restore into pg_catalog schema
Date
Msg-id CA+TgmoYr=-M0p71TiEJNcT_RZ3L1BWDZXrua21F5gh34zR68EA@mail.gmail.com
Whole thread Raw
In response to Re: erroneous restore into pg_catalog schema  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: erroneous restore into pg_catalog schema
List pgsql-hackers
On Tue, Jan 15, 2013 at 3:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Or perhaps there is some other way to make sure that the user "really
>> meant it", like refusing to create in pg_catalog unless the schema
>> name is given explicitly.  I kind of like that idea, actually.
>
> That does seem attractive at first glance.  Did you have an
> implementation in mind?  The idea that comes to mind for me is to hack
> namespace.c, either to prevent activeCreationNamespace from getting set
> to "pg_catalog" in the first place, or to throw error in
> LookupCreationNamespace and friends.  I am not sure though if
> LookupCreationNamespace et al ever get called in contexts where no
> immediate object creation is intended (and thus maybe an error wouldn't
> be appropriate).

As far as I can see, the principle place we'd want to hack would be
recomputeNamespacePath(), so that activeCreationNamespace never ends
up pointing to pg_catalog even if that's explicitly listed in
search_path.  The places where we actually work out what schema to use
are RangeVarGetCreationNamespace() and
QualifiedNameGetCreationNamespace(), but those don't seem like they'd
need any adjustment, unless perhaps we wish to whack around the "no
schema has been selected to create in" error message in some way.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Christopher Browne
Date:
Subject: Re: [PATCH] COPY .. COMPRESSED
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCH] COPY .. COMPRESSED