On Monday, September 03, 2012 10:54:23 PM Tom Lane wrote:
> Andres Freund <andres@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
