On 12/6/19 6:20 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> I've just been looking at that. load_external_function() doesn't >> actually do anything V1-ish with the value, it just looks up the symbol >> using dlsym and returns it cast to a PGFunction. Is there any reason I >> can't just use that and cast it again to the callback function type? > TBH, I think this entire discussion has gone seriously off into the > weeds. The original design where we just let a shared_preload_library > function get into a hook is far superior to any of the overcomplicated > kluges that are being discussed now. Something like this, for instance: > >>>> ssl_passphrase_command='#superlib.so,my_rot13_passphrase' > makes me positively ill. It introduces problems that we don't need, > like how to parse out the sub-parts of the string, and the > quoting/escaping issues that will come along with that; while from > the user's perspective it replaces a simple and intellectually-coherent > variable definition with an unintelligible mess. > >
Yeah, you have a point. Bruce was worried about what would happen if we defined both ssl_passphrase_command and ssl_passphrase_callback. The submitted patch let's the callback have precedence, but it might be cleaner to error out with such a config. OTOH, that wouldn't be so nice on a reload, so it might be better just to document the behaviour. He was also worried that multiple shared libraries might try to provide the hook. I think that's fairly fanciful, TBH. It comes into the category of "Don't do that." cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
