Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers