Re: erroneous restore into pg_catalog schema
От | Andres Freund |
---|---|
Тема | Re: erroneous restore into pg_catalog schema |
Дата | |
Msg-id | 20130514111655.GA4589@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: erroneous restore into pg_catalog schema (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: erroneous restore into pg_catalog schema
|
Список | pgsql-hackers |
On 2013-05-13 21:04:06 -0400, Stephen Frost wrote: > * Marko Kreen (markokr@gmail.com) wrote: > > On Sat, May 04, 2013 at 10:57:44PM +0200, Dimitri Fontaine wrote: > > > Other than adminpack, I know of PGQ installing their objects in > > > pg_catalog. They only began doing that when switching to the CREATE > > > EXTENSION facility. And they set relocatable to false. > > > > FYI - PgQ and related modules install no objects into pg_catalog. > > > > I used schema='pg_catalog' because I had trouble getting schema='pgq' > > to work. I wanted 'pgq' schema to live and die with extension, > > and that was only way I got it to work on 9.1. > > I've read through this thread and I think you're the only person here > that I actually agree with.. I like the idea of having a schema that > lives & dies with an extension. imv, putting random objects (of ANY > kind) into pg_catalog is a bad idea. Sure, it's convenient because it's > always in your search_path, but that, imv, means we should have a way to > say "these schemas are always in the search_path", not that we should > encourage people to dump crap into pg_catalog. I don't disagree, but how is that relevant for fixing the issue at hand? We still need to fix restores that currently target the wrong schema in a backward compatible manner? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: