On Thu, Nov 14, 2019 at 02:07:58PM -0300, 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.
Yeah, I was unclear how the function name would be specified. I thought it would just be hard-coded, but I like the above better. I am still unclear how parameters are passed. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +