Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-12-05 23:01:28 +0200, Heikki Linnakangas wrote:
>> 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.
> Hm. I'd guessed that we wouldn't use the connection string to pass down
> the executable name and the datadir now that we're inventing a separate
> function. But maybe that's unneccessary.
> What parameters do we require to be set for that mode:
> * path to postgres
> * data directory
> * database name (single mode after all)
> * port, because of the shmem key? I'd say that's not important enough
> I think we also need to be able to pass some additional parameters to
> postgres:
> - config_file, hba_file, ... might be required to start pg in some environments
> - -P, -O , are sometimes required in cases single user mode is
> neccessary for data recovery.
Right, so by the time we're done, we'd still need a connection string or
the moral equivalent.
My feeling is that we should just treat the executable name and data
directory path as new connection parameters, which'd be ignored in
normal-connection mode, just as some other parameters will be ignored in
single-user mode. Otherwise we'll find ourselves building parameter
setting infrastructure that pretty much duplicates what's there for the
existing connection parameters.
I think the special-purpose command line switches you mention can be
passed through PGOPTIONS, rather than inventing a new parameter -- do you
have an objection to that?
> Not sure if we need anything but the pid of the postmaster be returned?
The new PQconnect routine would certainly hand back a PGconn. I think
we'd need a new query function PQchildPid(PGconn *) or some such to
provide access to the child process PID.
regards, tom lane