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

On 12/05/2013 10:37 PM, Robert Haas wrote:
> On Thu, Dec 5, 2013 at 3:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It might be unpleasant to use in some cases, though.
>
> Why would there be more than a few cases in the first place?  Who is
> going to use this beyond psql, pg_dump(all), and pg_upgrade, and why?

Well, you might want to use pgAdmin, or your other favorite admin tool. 
I'm not sure how well it would work, and I think it's OK if we say 
"sorry, can't do that", but it's not a crazy thing to want.

>> Another issue is that we have too many variants of PQconnect already;
>> which of them are we prepared to clone for this hypothetical new
>> connection method?
>
> PQconnectdbParams, I assume.  Isn't that the one to rule them all,
> modulo async connect which I can't think is relevant here?

Right. Not all of the parameters will make sense for a stand-alone 
backend though, like the hostname and port number. And I think you need 
need a new parameter to pass the path to the 'postgres' executable, 
unless we re-use the host parameter for that.

> Or don't clone that one but instead have
> PQnextConnectionShouldForkThisBinary('...') and let the psql/pg_dump
> switch be --standalone=full-path-to-the-postgres-binary.

I think a separate function makes more sense.

- Heikki