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