Re: psql commandline conninfo

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