Re: contrib function naming, and upgrade issues

>>>>> "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.

Tom> I think you are missing the point.

Nope.

Tom> There are certainly *potential* problems from common function
Tom> names in different .so's, but that does not translate to
Tom> 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 their
Tom> symbols to those globally known by the linker --- at least on
Tom> 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 is
Tom> not all that large. So I think the actual risks posed by
Tom> 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 justify
Tom> imposing any upgrade pain on users.

OK. I will maintain binary compatibility in my patch.

--
Andrew.