On Wed, 13 Nov 2019 at 13:08, Bruce Momjian <br...@momjian.us> wrote:
> On Tue, Nov 12, 2019 at 09:51:33PM -0500, Bruce Momjian wrote: > > On Sun, Nov 10, 2019 at 01:01:17PM -0600, Magnus Hagander wrote: > > > On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian <br...@momjian.us> wrote: > > > > One of the main reasons there being to be easily able to transfer more > state > > > and give results other than just an exit code, no need to deal with > parameter > > > escaping etc. Which probably wouldn't matter as much to an SSL > passphrase > > > command, but still. > > > > I get the callback-is-easier issue with shared objects, but are we > > expecting to pass in more information here than we do for > > archive_command? I would think not. What I am saying is that if we > > don't think passing things in works, we should fix all these external > > commands, or something. I don't see why ssl_passphrase_command is > > different, except that it is new. > Or is it related to _securely_passing something? > Yes > > Also, why was this patch posted without any discussion of these issues? > > Shouldn't we ideally discuss the API first? > > I wonder if every GUC that takes an OS command should allow a shared > object to be specified --- maybe control that if the command string > starts with a # or something. > Very good idea -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Solutions for the Enterprise
