Andrew Dunstan <andrew@dunslane.net> writes:
> On 12/07/2010 11:13 AM, Robert Haas wrote:
>> Why not? This feature seems to be pretty heavily designed around the
>> assumption that everything's going to live in one schema, so is there
>> any harm in making that explicit?
> In previous discussions IIRC the consensus was that we should not force
> that on either Extension writers or users.
It's not very hard to imagine a complicated extension wanting to spread
itself across multiple schemas --- for example, one schema for "public"
functions and a separate one for internal objects might be desirable.
So I'm definitely not in favor of trying to force a single-schema design
on people.
Although ... if the restriction did exist, one could imagine building
that complex extension in two parts, foo and foo_internal. To make this
work conveniently you'd need some sort of "requires" mechanism for
extensions. The other problem is that foo will certainly need to know
which schema foo_internal got loaded into.
Anyway the main problem at the moment is that the proposed design is
meant to allow "relocatable" extensions, but it doesn't behave
pleasantly in the case where somebody tries to relocate a
non-relocatable extension.
It also strikes me that the plan appears to be to support ALTER
EXTENSION SET SCHEMA to relocate an extension after the fact, but this
will absolutely *not* work with the available infrastructure. Remember
that example of a SQL function with a SET search_path = @extschema@
option? There's no way to fix that up, nor any other case where the
schema was substituted into an object declaration. So I'm back to
thinking that the textual-substitution idea is fundamentally deficient.
regards, tom lane
