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
