Skip site navigation (1) Skip section navigation (2)

Re: erroneous restore into pg_catalog schema

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
Subject: Re: erroneous restore into pg_catalog schema
Date: 2013-01-15 20:40:02
Message-ID: CA+TgmoYr=-M0p71TiEJNcT_RZ3L1BWDZXrua21F5gh34zR68EA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Jan 15, 2013 at 3:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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


In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2013-01-15 20:42:48
Subject: Re: [PATCH] COPY .. COMPRESSED
Previous:From: Christopher BrowneDate: 2013-01-15 20:37:07
Subject: Re: [PATCH] COPY .. COMPRESSED

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group