Robert Haas <robertmhaas@gmail.com> writes:
> Yeah, seriously. I don't understand what the big deal is here. The
> right design here is 99.44% clear here, and the committer (presumably
> Tom) can handle the other 0.56% however he'd like. Let's do this and
> move on.
Yeah, but the remaining 0.56% is an important decision, not least because
it's got security implications. I think we need some consensus not just
a unilateral committer decision.
I'm pretty much persuaded by Andres' point that we should not allow a
child process to be launched under a client app without clear permission
from the code of the app (and *not* just some environment variable that
might have been set far away, perhaps by someone who doesn't know what the
app assumes about SIGCHLD etc). So a separate connection call seems like
not a bad idea. In the case of psql and pg_dump it'd be reasonable to
invent a separate command line switch that drives use of this call instead
of normal PQconnect. Doing that, and *not* allowing the text of the
connection string to determine it, seems like it pretty well solves any
security objections. It might be unpleasant to use in some cases, though.
Another issue is that we have too many variants of PQconnect already;
which of them are we prepared to clone for this hypothetical new
connection method?
regards, tom lane