Re: search_path vs extensions - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: search_path vs extensions
Date
Msg-id 4A1FFFE4.7090502@dunslane.net
Whole thread Raw
In response to Re: search_path vs extensions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

Tom Lane wrote:
> Dimitri Fontaine <dfontaine@hi-media.com> writes:
>   
>> Le 29 mai 09 à 16:11, Andrew Dunstan a écrit :
>>     
>>> 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.
>>>       
>
>   
>> This coupled with Peter's idea of nested namespace seems a killer  
>> feature for me.
>>     
>
> What it sounds like to me is an amazingly complicated gadget with
> absolutely no precedent of successful use anywhere.  We'll spend a year
> fooling with the details of this and be no closer to actually solving
> the problem at hand, namely getting a simple workable extension
> packaging facility.
>   

Well, the part about no precedent is not true. See 
<http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/r0000910.htm> 
for example. I didn't dream up the idea out of thin air ;-) (I pretty 
much started my computing career over 20 years ago working on DB2).

However, the part about it being complex is true.

And that is why I agree completely that we should not hold up the 
extension work waiting for it.

cheers

andrew


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_migrator and an 8.3-compatible tsvector data type
Next
From: Aidan Van Dyk
Date:
Subject: Re: PostgreSQL Developer meeting minutes up