Re: Proof of concept: standalone backend with full FE/BE protocol

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