On 2013-12-06 11:02:48 -0500, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > 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.
Right. > 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? I am not sure if they currently will get recognized early enough and whether permission checking will interferes, but if so, that's probably fixable. > > 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. I was thinking of a pid_t* argument to the new routine, but it's likely unneccessary as we're probably going to end up storing it in PGconn anyway. There's the question what we're going to end up doing with the current single user mode? There's some somewhat ugly code around for it... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
