>>>>> "Tom" == Tom Lane <t...@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. 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
