| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: ssl passphrase callback |
| Date: | 2019-12-07 17:16:17 |
| Message-ID: | 30151.1575738977@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
> 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.
I think it would be up to the extension that's using the hook to
decide what to do if ssl_passphrase_command is set. It would not
be our choice, and it would certainly not fall to us to document it.
> 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."
Again, it's somebody else's problem. We have plenty of hooks that
are of dubious use for multiple extensions, so why should this one be
held to a higher standard?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-12-07 17:20:51 | Re: Windows buildfarm members vs. new async-notify isolation test |
| Previous Message | Tom Lane | 2019-12-07 16:34:12 | Re: verbose cost estimate |