From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] Add session_preload_libraries configuration parameter |
Date: | 2013-07-09 12:07:23 |
Message-ID: | 51DBFCFB.3080000@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7/8/13 4:37 AM, Dimitri Fontaine wrote:
>> I don't know of any actual legitimate uses of local_preload_libraries.
>> I recall that the plpgsql debugger was meant to use it, but doesn't
>> anymore. So it's hard to judge what to do about this, without any
>> actual use cases.
>
> Well there's my preprepare thing at
>
> https://github.com/dimitri/preprepare
preprepare has an SQL function as entry point, so you don't need to
preload it.
> I don't think that the whitelisting is actually used in a way to allow
> for non superusers to load modules in the field, because the only way to
> do that with local_preload_libraries that I know of is to edit the
> postgresql.conf file and reload.
>
> alter role dim set local_preload_libraries = 'auto_explain';
> ERROR: 55P02: parameter "local_preload_libraries" cannot be set after connection start
I think the idea was to use PGOPTIONS to load it, controlled by the
client side.
From | Date | Subject | |
---|---|---|---|
Next Message | ivan babrou | 2013-07-09 12:25:50 | Re: Millisecond-precision connect_timeout for libpq |
Previous Message | Kyotaro HORIGUCHI | 2013-07-09 10:55:55 | Re: Add visibility map information to pg_freespace. |