On Thu, Dec 5, 2013 at 3:05 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
Yep. > It might be unpleasant to use in some cases, though. Why would there be more than a few cases in the first place? Who is going to use this beyond psql, pg_dump(all), and pg_upgrade, and why? > 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? PQconnectdbParams, I assume. Isn't that the one to rule them all, modulo async connect which I can't think is relevant here? Or don't clone that one but instead have PQnextConnectionShouldForkThisBinary('...') and let the psql/pg_dump switch be --standalone=full-path-to-the-postgres-binary. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers