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

Re: Modifying and solidifying contrib

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: David Fetter <david(at)fetter(dot)org>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Glaesemann <grzm(at)seespotcode(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Modifying and solidifying contrib
Date: 2007-01-29 21:16:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Bruce Momjian wrote:
> David Fetter wrote:
>> It's 982 functions as of this writing in CVS TIP's contrib.  Do you
>> not get how wacky it is to have that many functions, none of which
>> have any collision-prevention built into their install scripts, in a
>> flat namespace?
> We currently have 1695 standard functions.  I don't see a problem with
> putting the extensions all in one schema, but I also don't see the
> point.

I certainly don't see the point.  But I do see a considerable point in 
having extensions use their own schemas. The fact that we have 1695 
standard functions means we bear the responsibility of ensuring we don't 
have name clashes among them. We should encourage extension authors by 
example to use the namespace facility to relieve themselves of having to 
ensure they don't clash not only with the standard functions but with 
other extensions. IOW we should act with respect to the namespace for 
extensions we distribute just like we would reasonably expect authors of 
third party extensions to behave.

For backwards compatibility, we might be well advised also to distribute 
load scripts that put extension objects in the public schema as is done 
now, but this should be a deprecated practice, IMNSHO.



In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2007-01-29 21:18:21
Subject: Re: Modifying and solidifying contrib
Previous:From: Bruce MomjianDate: 2007-01-29 20:59:55
Subject: Re: Modifying and solidifying contrib

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