Re: Proof of concept: standalone backend with full FE/BE protocol - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proof of concept: standalone backend with full FE/BE protocol
Date
Msg-id 25538.1346705663@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proof of concept: standalone backend with full FE/BE protocol  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Proof of concept: standalone backend with full FE/BE protocol  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Next
From: Tom Lane
Date:
Subject: Yet another issue with pg_upgrade vs unix_socket_directories