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

Re: contrib function naming, and upgrade issues

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Subject: Re: contrib function naming, and upgrade issues
Date: 2009-03-22 01:34:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Saturday 21 March 2009 12:27:27 Tom Lane wrote:
> Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> > "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> >  Tom> I agree that this wasn't an amazingly good choice, but I think
> >  Tom> there's no real risk of name collisions because fmgr only
> >  Tom> searches for such names within the particular .so.
> >
> > Oh, if only life were so simple.
> I think you are missing the point.  There are certainly *potential*
> problems from common function names in different .so's, but that does not
> translate to evidence of *actual* problems in the Postgres environment.
> In particular, I believe that we load .so's without adding their symbols
> to those globally known by the linker --- at least on platforms where
> that's possible.  Not to mention that the universe of other .so's we
> might load is not all that large.  So I think the actual risks posed by
> contrib/hstore are somewhere between minimal and nonexistent.
> The past discussions we've had about developing a proper module facility
> included ways to replace not-quite-compatible C functions.  I think that
> we can afford to let hstore go on as it is for another release or two,
> in hopes that we'll have something that makes a fix for this transparent
> to users.  The risks don't look to me to be large enough to justify
> imposing any upgrade pain on users.

We've been talking about this magical "proper module facility" for a few 
releases now... are we still opposed to putting contrib modules in thier own 
schema? People who took my advice and did that for tsearch were mighty happy 
when 8.2 broke at the C level, and when 8.3 broke all around. Doing that for 
hstore now would make the transition a little easier in the future as well. 

Robert Treat

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-03-22 01:49:18
Subject: Re: contrib function naming, and upgrade issues
Previous:From: Tom LaneDate: 2009-03-22 00:35:57
Subject: Re: Can we drop ABSTIME?

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