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

Re: erroneous restore into pg_catalog schema

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-29 19:30:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Robert Haas escribió:
> 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, are you working on this?

Álvaro Herrera      
PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: Marko TiikkajaDate: 2013-01-29 20:37:12
Subject: Re: pg_dump --pretty-print-views
Previous:From: Alvaro HerreraDate: 2013-01-29 18:55:44
Subject: Re: [COMMITTERS] pgsql: Tolerate timeline switches while "pg_basebackup -X fetch" is run

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