From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Daniel Farina <daniel(at)heroku(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Christoph Berg <cb(at)df7cb(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Runtime SHAREDIR for testing CREATE EXTENSION |
Date: | 2012-03-02 21:50:46 |
Message-ID: | CA+TgmoYFi2XKQ1E36PZBRxsh1TCK+r1YCo1RDKPNGFiLyLGPrQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 2, 2012 at 1:53 PM, Daniel Farina <daniel(at)heroku(dot)com> wrote:
> On Fri, Mar 2, 2012 at 10:37 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> On tis, 2012-02-28 at 11:00 -0800, Daniel Farina wrote:
>>> I'd really like to support libraries (C or otherwise) of multiple
>>> versions at the same time, when the underlying library permits.
>>
>> What's preventing you from doing that now? You need to name all the
>> symbols differently, of course.
>
> That's the problem: not really practical in a wider ecosystem of C
> libraries, especially if the library produces multiple versions. (Or,
> not practical unless someone writes some credible
> symbol-version-mangling-magic)
>
> But is it unsurmountable? -- dlsym returns a function pointer, and one
> would build up the operator table for the version of the extension at
> hand, so one might have ltree "version 1.01" and ltree "version 2.3"
> fields in the same database.
That might be possible, but it seems largely unrelated to the topic of
this thread, unless I am missing something.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2012-03-02 21:56:45 | Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation) |
Previous Message | Kevin Grittner | 2012-03-02 21:12:10 | Re: COPY with hints, rebirth |