Re: erroneous restore into pg_catalog schema

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: erroneous restore into pg_catalog schema
Дата
Msg-id 5190A903.8040805@vmware.com
обсуждение исходный текст
Ответ на Re: erroneous restore into pg_catalog schema  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: erroneous restore into pg_catalog schema
Список pgsql-hackers
On 09.05.2013 18:24, Robert Haas wrote:
> On Sat, May 4, 2013 at 3:59 PM, Tom Lane<tgl@sss.pgh.pa.us>  wrote:
>> Given the lack of any good alternative proposals, I think we should
>> press ahead with this approach.  We still need doc updates and fixes
>> for the affected contrib module(s), though.  Also, in view of point 2,
>> it seems like the extensions code should test for and reject an attempt
>> to set a relocatable extension's schema to pg_catalog.  Otherwise you'd
>> be likely to get not-too-intelligible errors from the extension script.
>
> I looked into this a bit more.  It seems that adminpack is OK: it
> already qualifies all of the objects it creates with the pg_catalog
> schema.  With the previous patch applied, all of the built-in
> extensions seem to install OK (except for uuid-ossp which I'm not set
> up to build, but it doesn't look like a problem)  make check-world
> also passes.  (adminpack actually has no regression tests, not even a
> test that the extension installs, but it does.)
>
> I looked for a suitable place to update the documentation and I don't
> have any brilliant ideas.  The point that we're going to forbid
> relocatable extensions from being created in pg_catalog seems too
> minor to be worth noting; we don't document every trivial error
> message that can occur for every command in the manual.  The point
> that we won't create ANY objects in pg_catalog unless the CREATE
> statement schema-qualifies the object name seems like it would be
> worth pointing out, but I don't see an obvious place to do it.
> Suggestions?
>
> In the attached new version of the patch, I added an explicit check to
> prevent relocatable extensions from being created in pg_catalog.

Do we really want to forbid that? What's wrong with doing e.g:
 create extension btree_gist schema pg_catalog;

I would consider btree_gist, along with many other extensions, as 
core-enough parts of the system that you'd want to install them in 
pg_catalog, to make them readily available for everyone. Besides, not 
allowing that would break backwards-compatibility; I bet there are a lot 
of people doing exactly that.

- Heikki



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Fast promotion failure
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Fast promotion failure