Re: ssl passphrase callback

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ssl passphrase callback
Дата
Msg-id 19596.1575674454@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ssl passphrase callback  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Ответы Re: ssl passphrase callback  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Re: ssl passphrase callback  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-hackers
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.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ranier Vilela
Дата:
Сообщение: RE: [Proposal] Level4 Warnings show many shadow vars
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Windows buildfarm members vs. new async-notify isolation test