On Saturday 21 March 2009 12:27:27 Tom Lane wrote:
> Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> > "Tom" == Tom Lane <tgl@sss.pgh.pa.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
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
