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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, hlinnaka(at)iki(dot)fi
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Date: 2012-09-04 04:01:17
Message-ID: CA+TgmoYuazwXbjUJVO5QNdqORRPKod=A5V3VRp0cRPaVG753=g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 3, 2012 at 4:38 PM, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Harshitha S 2012-09-04 04:15:04 Re: [GENERAL] Reduce the time to know trigger_fi​le's existence
Previous Message Tom Lane 2012-09-04 03:36:21 Re: index-only scans versus serializable transactions