Re: contrib function naming, and upgrade issues - Mailing list pgsql-hackers

From Tom Lane
Subject Re: contrib function naming, and upgrade issues
Date
Msg-id 23061.1237652847@sss.pgh.pa.us
Whole thread Raw
In response to Re: contrib function naming, and upgrade issues  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: contrib function naming, and upgrade issues  (Robert Treat <xzilla@users.sourceforge.net>)
Re: contrib function naming, and upgrade issues  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: win32 open item
Next
From: "Joshua D. Drake"
Date:
Subject: Re: small but useful patches for text search