Re: contrib function naming, and upgrade issues

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> I agree that this wasn't an amazingly good choice, but I thinkTom> there's no real risk of name collisions because
fmgronlyTom> searches for such names within the particular .so.
 
>> Oh, if only life were so simple.
Tom> I think you are missing the point.

Nope.
Tom> There are certainly *potential* problems from common functionTom> names in different .so's, but that does not
translatetoTom> evidence of *actual* problems in the Postgres environment.
 

It is true that I have no reason to believe that anyone has ever
encountered any problems due to name collisions between hstore and
something else. The only question is how to trade off the potential
risks against the known difficulties regarding upgrading; I'm quite
happy to accept the conclusion that the risk is not sufficient to
justify the upgrade pain, but only if the risk is being correctly
assessed.
Tom> In particular, I believe that we load .so's without adding theirTom> symbols to those globally known by the linker
---at least onTom> platforms where that's possible.
 

This is false; in the exact reverse of the above, we explicitly
request RTLD_GLOBAL on platforms where it exists.
Tom> Not to mention that the universe of other .so's we might load isTom> not all that large.  So I think the actual
risksposed byTom> contrib/hstore are somewhere between minimal and nonexistent.
 

The problem extends not only to other loaded .so's, but also to every
library linked into the postmaster itself, every library linked into
another loaded .so, and every .so (and associated libs) dynamically
loaded by another .so (e.g. modules loaded by pls).

(-Bsymbolic (or equivalent) would negate all of these, as far as I can
tell.)
Tom> The risks don't look to me to be large enough to justifyTom> imposing any upgrade pain on users.

OK. I will maintain binary compatibility in my patch.

-- 
Andrew.