Casey Duncan wrote:
> On Dec 12, 2006, at 3:37 PM, Tom Lane wrote:
>
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>> Right. Here's the patch I just knocked up, which seems to Just
>>> Work (tm) ;-)
>>
>> The main objection I can see to this is that you'd get a fairly
>> unhelpful message if you intended a conninfo string and there was
>> anything wrong with your syntax (eg, misspelled keyword). Maybe we
>> should go with the conn: bit, although really that doesn't seem any
>> less likely to collide with actual dbnames than the "does it contain
>> "="" idea. Anyone have other ideas how to disambiguate?
>
> I would personally prefer a real option over a prefix, i.e. --
> dbconn="service=foo" though the inline conninfo string in place of
> the dbname would be ideal.
>
> Perhaps like Tom suggests, if the value matches a conninfo regex
> (slightly more rigid than just containing an equals character) then
> we assume it is a conninfo string, but never try it as a dbname. If
> someone has a database named like a conninfo string (c'mon folks ;^)
> then they would need to pass it as explicitly an argument to '-d' or
> '--dbname', not as a bare argument.
>
You are confusing two things here. The way the patch is written it simply
interprets the parameter passed to libpq - it has no idea what was used
(if anything) on the commandline. The alternative, as Tom pointed out, is
to patch every client.
I'm inclined to say we should go back almost to my original suggestion: a
param that starts with conn: and contains an = is conclusively presumed to
be a conninfo string.
The workaround for a db name like that (say conn:foo=bar) is to use
"conn:dbname='conn:foo=bar'". You'll soon get tired of that and rename the
db to something sane :-)
cheers
andrew