On Dec 12, 2006, at 5:16 PM, Andrew Dunstan wrote:
> 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 was speaking from and end-user point of view, but I see your point.
It's certainly attractive to just patch libpq and be done. However,
that does have the side-effect of implicitly propagating the behavior
to all libpg client software. That may be more unpleasantly
surprising to more people then just changing the built-in postgresql
client utilities. But then again it could also be considered a
feature 8^)
-Casey