Re: ssl passphrase callback
От | Craig Ringer |
---|---|
Тема | Re: ssl passphrase callback |
Дата | |
Msg-id | CAMsr+YE8A5Z0PXuzddrwJ9C_F=jXDaaxf97hO94TJ3aFzGPW5Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ssl passphrase callback (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Sat, 7 Dec 2019 at 07:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andrew Dunstan <andrew.dunstan@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.
+1000 from me on that.
В списке pgsql-hackers по дате отправления: