Re: Proof of concept: standalone backend with full FE/BE protocol
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>, hlinnaka@iki.fi
Date: 2012-09-04T04:01:17Z
Lists: pgsql-hackers
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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Remove now redundant pgpipe code.
- d2c1740dc275 9.2.0 cited