On Monday, September 03, 2012 10:54:23 PM Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On Monday, September 03, 2012 10:23:52 PM Tom Lane wrote: > >> I'm reluctantly coming to the conclusion that we can't pass these > >> parameters through the regular libpq connection string mechanism, and > >> will have to invent something else. That's awfully nasty though; > >> it will pretty much cripple the idea that this would be a simple way to > >> invoke a quasi-embedded variant of Postgres. > > > > What I am asking myself is: why does that have to go through the normal > > PQconnectdb* api? This is something completely new and very well might > > grow more features that are not necessarily easy to press into > > PQconnectdb(). > > Well, what that's mostly going to result in is a huge amount of > duplication :-(. psql, pg_dump, and anything else that wants to support > this will need some alternative command line switch and an alternative > code path to call PQstartServer. I'd hoped to avoid all that. Note > that the POC patch involved not one single line of change in those > application programs. I can see why that would be nice, but is it really realistic? Don't we expect some more diligence in applications using this against letting such a child continue to run after ctrl-c/SIGTERMing e.g. pg_dump in comparison to closing a normal database connection? Besides the already mentioned security issues I would argue that its a good thing to make the applications authors think about the special requirements of "embedding" PG.
Greetings, Andres -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
