On Mon, Sep 3, 2012 at 4:38 PM, Andres Freund <and...@2ndquadrant.com> wrote: > 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(). > > PQServer > PQstartServer(const char **keywords, const char **values); > > or whatever seems to be more future proof especially considering the > possibility that this will grow into something more featureful.
I tend to agree. Another idea here might be to stick with Tom's original idea of making it a connection parameter, but have it be turned off by default. In other words, if an application wants to allow those parameters to be used, it would need to do PQenableStartServer() first. If it doesn't, those connection parameters will be rejected. Not 100% sure that's enough to fix the problem, but maybe... -- 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
