Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> 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
> validity.
>
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.
cheers
andrew