Re: search_path vs extensions - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: search_path vs extensions
Date
Msg-id 4A1FED0A.40500@dunslane.net
Whole thread Raw
In response to Re: search_path vs extensions  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: search_path vs extensions  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-hackers

Peter Eisentraut wrote:
> On Thursday 28 May 2009 02:57:00 Josh Berkus wrote:
>   
>> Personally, if we're tracking stuff through special dependancies which
>> pg_dump will be aware of anyway, I don't see why extension objects
>> should go into a special schema.
>>     
>
> But they clearly have to go into *some* schema, and it would add some clarity 
> to the world if we made a recommendation which one that is.  Which is what 
> some of the subproposals really come down to.
>   

Even that's going to be hard, frankly. The usage pattern is likely to be 
too varied for any one-size-fits-all recommendation.

Proposals to allow a choice of schema at install time sound nice but in 
practice they are a recipe for massive headaches and maintenance 
nightmares, I think. It means no extension author will be able to 
hardcode the schema name in any view, function etc. Yuck.

I think almost all these difficulties could be overcome if we had some 
sort of aliasing support, so that arbitrary objects in schema a could be 
aliased in schema b.  If that were in place, best practice would 
undoubtedly be for each module to install in its own schema, and for the 
DBA to alias what is appropriate to their usage scenario. But unless 
someone wants to tackle that  I think we should leave schema management 
entirely alone, and leave it up to the extension author / DBA between them.

cheers

andrew


pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Re: Warnings in compile
Next
From: Tom Lane
Date:
Subject: Re: pg_migrator and an 8.3-compatible tsvector data type