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

Re: contrib function naming, and upgrade issues

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: contrib function naming, and upgrade issues
Date: 2009-03-21 16:27:27
Message-ID: 23061.1237652847@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "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.

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

In response to

Responses

pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2009-03-21 16:55:19
Subject: Re: small but useful patches for text search
Previous:From: Tom LaneDate: 2009-03-21 16:15:31
Subject: Re: win32 open item

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