On 09.05.2013 18:24, Robert Haas wrote:
On Sat, May 4, 2013 at 3:59 PM, Tom Lane<t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
