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 по дате отправления: