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
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 |