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.


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:

Reply via email to