Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I have been working on providing psql with the ability to accept a libpq
conninfo string, so that the following now works for me:
psql "conn:service=sname user=uname"
Perhaps this should be implemented in libpq, not at the psql level?
Otherwise you're going to have to do it over for each client program.
Just as well I haven't spent much time on it, eh?
2. If this is ok, what should the prefix be? is "conn:" ok?
I'd prefer to dispense with the conn:, so that this looks somehow
designed in rather than bolted on after the fact.
well, I thought this made it look slightly URLish, a bit like a jbdc
URL. But OK. no big deal.
I'm tempted to suggest that if the "dbname" includes "=" it should be
considered a conninfo string; perhaps also after checking keyword
Now I look at fe-connect.c more closely, I'm tempted just to try parsing
the dbname param as a conninfo string, and if it doesn't work fall back
on a plain dbname. I could greatly reduce the chance of following the
failure path by just looking for an = but I think anything more is
likely to be redundant.
3. Should we append settings from other switches to the conninfo (e.g.
-U or -h), or should we just ignore them? If we ignore them should we
warn about that if they are present?
Do we complain about duplicate keywords in conninfo now? I think not,
so appending the other switches would have the result of overriding what
is in conninfo, which is probably reasonable. (Actually, if you
implement this in libpq, there's probably no need to form the appended
string explicitly --- just process the other options of PQsetdbLogin()
after the conninfo.)
OK. I think this just falls out.
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster