Re: ssl passphrase callback
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
Bruce Momjian <bruce@momjian.us>,
Magnus Hagander <magnus@hagander.net>,
Tomas Vondra <tomas.vondra@2ndquadrant.com>,
Simon Riggs <simon@2ndquadrant.com>,
Robert Haas <robertmhaas@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-12-06T23:20:54Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Provide a TLS init hook
- 896fcdb230e7 13.0 landed
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