On 2019-Nov-14, Andrew Dunstan wrote:
> 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.
Using the generic interface has the drawback that the user can make more
mistakes. I think that's part of Bruce's issue with it (although I may
misinterpret.)
I think if you add most of it as a new entry point in dfmgr.c (where you
can leverage internal_library_load) and returns a function pointer to
the user specified function, it's all that much additional code.
(I don't think you can use load_external_function as is, because it
assumes fmgr V1 calling convention, which I'm not sure serves your case.
But then maybe it does. And if not, then those 10 lines should be very
similar to the code you'd need to add.)
> 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.
Yeah, you can do that too I guess, but I'm not sure I see that as simpler.
> Also, calling this 'ssl_passphrase_command' seems a little odd.
We could just rename ssl_passphrase_command to something more
generic, and add the existing name to map_old_guc_names to preserve
compatibility with pg12. Maybe the new name could be simply
ssl_passphrase or perhaps ssl_passphrase_{reader,getter,pinentry}.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services