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

Reply via email to