On Mon, Sep 3, 2012 at 4:38 PM, Andres Freund <andres@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
