On 11/14/19 12:07 PM, Alvaro Herrera wrote:
> On 2019-Nov-14, Bruce Momjian wrote:
>
>> I was assuming if the variable starts with a #, it is a shared object,
>> if not, it is a shell command:
>>
>> ssl_passphrase_command='#/lib/x.so'
>> ssl_passphrase_command='my_command a b c'
> Note that the proposed patch doesn't use a separate GUC -- it just uses
> shared_preload_libraries, and then it is the library that's in charge of
> setting up the function. We probably wouldn't like to have multiple
> settings that all do the same thing, such as recovery target (which
> seems to be a plentiful source of confusion).
>
> Changing the interface so that the user has to specify the function name
> (not the library name) in ssl_passphrase_command closes that ambiguity
> hole.
>
> Note that if you specify only the library name, it becomes redundant
> w.r.t. shared_preload_libraries; you could have more than one library
> setting the function callback and it's hard to see which one wins.
>
> I think something like this would do it:
> ssl_passphrase_command='#superlib.so,my_rot13_passphrase'
>
> This way, the library can still create any custom GUCs it pleases/needs,
> but there's no possible confusion as to the function that's going to be
> called.
I guess this would work. There would have to be a deal of code to load
the library and lookup the symbol. Do we really think it's worth it?
Leveraging shared_preload_libraries makes this comparatively simple.
Also, calling this 'ssl_passphrase_command' seems a little odd.
A simpler way to handle it might be simply to error out and refuse to
start if both ssl_passphrase_function is set and ssl_passphrase_command
is set.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
