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

Re: contrib function naming, and upgrade issues

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: contrib function naming, and upgrade issues
Date: 2009-03-22 11:09:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
>>>>> "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.


 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

 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

 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.


In response to

pgsql-hackers by date

Next:From: Andrew GierthDate: 2009-03-22 11:42:49
Subject: Re: contrib function naming, and upgrade issues
Previous:From: Robert HaasDate: 2009-03-22 04:13:35
Subject: Re: small but useful patches for text search

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