From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Petr Jelinek" <pjmodos(at)pjmodos(dot)net> |
Cc: | "'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-26 18:53:43 |
Message-ID: | 22835.1359226423@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Petr Jelinek" <pjmodos(at)pjmodos(dot)net> writes:
>> What exactly do you have in mind there? The way we load extensions, they
>> can't (AFAIK) see each other's defined symbols, so you couldn't really make
>> an independent extension that would call functions in plpgsql. This is not
>> really open for debate, either, as changing that would risk creating symbol
>> collisions between modules that never had to worry about polluting global
>> namespace before.
> I can call functions that are exported by plpgsql.so just fine from
> different extension now, I just have to preload the plpgsql.so (via LOAD or
> guc) first, so I don't see what is the problem here.
[ 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-01-26 19:12:19 | Re: plpgsql_check_function - rebase for 9.3 |
Previous Message | Pavel Stehule | 2013-01-26 18:38:41 | Re: plpgsql_check_function - rebase for 9.3 |