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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, 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-03 20:54:23
Message-ID: 25538.1346705663@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-09-03 21:00:15 Yet another issue with pg_upgrade vs unix_socket_directories
Previous Message Tom Lane 2012-09-03 20:50:22 Re: Proof of concept: standalone backend with full FE/BE protocol