Skip site navigation (1) Skip section navigation (2)

Re: search_path vs extensions

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Subject: Re: search_path vs extensions
Date: 2009-05-29 15:31:48
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

Tom Lane wrote:
> Dimitri Fontaine <dfontaine(at)hi-media(dot)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 
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.



In response to

pgsql-hackers by date

Next:From: Aidan Van DykDate: 2009-05-29 15:34:35
Subject: Re: PostgreSQL Developer meeting minutes up
Previous:From: Tom LaneDate: 2009-05-29 15:28:21
Subject: Re: pg_migrator and an 8.3-compatible tsvector data type

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group