Re: Runtime SHAREDIR for testing CREATE EXTENSION - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Runtime SHAREDIR for testing CREATE EXTENSION
Date
Msg-id CA+TgmoYFi2XKQ1E36PZBRxsh1TCK+r1YCo1RDKPNGFiLyLGPrQ@mail.gmail.com
Whole thread Raw
In response to Re: Runtime SHAREDIR for testing CREATE EXTENSION  (Daniel Farina <daniel@heroku.com>)
Responses Re: Runtime SHAREDIR for testing CREATE EXTENSION  (Daniel Farina <daniel@heroku.com>)
List pgsql-hackers
On Fri, Mar 2, 2012 at 1:53 PM, Daniel Farina <daniel@heroku.com> wrote:
> On Fri, Mar 2, 2012 at 10:37 AM, Peter Eisentraut <peter_e@gmx.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


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: COPY with hints, rebirth
Next
From: Simon Riggs
Date:
Subject: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)