Re: plpgsql_check_function - rebase for 9.3

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Petr Jelinek <pjmodos(at)pjmodos(dot)net>, 'Pavel Stehule' <pavel(dot)stehule(at)gmail(dot)com>, 'PostgreSQL Hackers' <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plpgsql_check_function - rebase for 9.3
Date: 2013-01-28 15:38:48
Message-ID: 51069B88.8000505@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 01/28/2013 10:11 AM, Peter Eisentraut wrote:
> On 1/26/13 1:53 PM, Tom Lane wrote:
>> [ pokes around... ] Hm, it appears that that does work on Linux,
>> because for some reason we're specifying RTLD_GLOBAL to dlopen().
>> TBH that seems like a truly horrid idea that we should reconsider.
>> Aside from the danger of unexpected symbol collisions between
>> independent loadable modules, I seriously doubt that it works like
>> that on every platform we support --- so I'd be very strongly against
>> accepting any code that depends on this working.
> Well, that would kill a lot of potentially useful features, including
> the transforms feature I've been working on and any kind of hook or
> debugger or profiler on an existing module. (How do plpgsql plugins
> work?) We also couldn't transparently move functionality out of the
> postgres binary into a module.
>
> I see the concern about symbol collisions. But you can normally work
> around that by prefixing exported symbols.
>

Yeah, I was just writing something a couple of days ago that leveraged
stuff in an extension, so it looks like this is wanted functionality. In
general we want to be able to layer addon modules, ISTM.

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2013-01-28 15:40:08 Re: pg_ctl idempotent option
Previous Message YAMAMOTO Takashi 2013-01-28 15:27:28 Re: SYSV shared memory vs mmap performance