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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2009-03-21 16:55:19 | Re: small but useful patches for text search |
Previous Message | Tom Lane | 2009-03-21 16:15:31 | Re: win32 open item |