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

Re: erroneous restore into pg_catalog schema

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(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-15 20:09:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Jan 14, 2013 at 2:07 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Tom Lane escribió:
>> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> > alvherre=# create extension adminpack;
>> > ERROR:  permission denied for schema pg_catalog
>> Um.  I knew that that module's desire to shove stuff into pg_catalog
>> would bite us someday.  But now that I think about it, I'm pretty sure
>> I recall discussions to the effect that there are other third-party
>> modules doing similar things.
> How about we provide a superuser-only function that an extension can
> call which will set enableSystemTableMods?  It would get back
> automatically to the default value on transaction end.  That way,
> extensions that wish to install stuff in pg_catalog can explicitely
> declare it, i, and the rest of the world enjoys consistent protection.

Or just document the existing GUC and make it something less than

But, really, I think allow_system_table_mods paints with too broad a
brush.  It allows both things that are relatively OK (like creating a
function in pg_catalog) and things that are rampantly insane (like
dropping a column from pg_proc).  It might be a good idea to make
those things controlled by two different switches.

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.

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2013-01-15 20:11:02
Subject: Re: [PERFORM] Slow query: bitmap scan troubles
Previous:From: Robert HaasDate: 2013-01-15 20:04:45
Subject: Re: erroneous restore into pg_catalog schema

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