Andrew Dunstan wrote:
> Tom Lane wrote:
>> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>>
>>> We change libpq from time to time. Besides, how many DBs are there that
>>> match the name pattern /^conn:.*=/ ? My guess is mighty few. So I don't
>>> expect lots of surprise.
>>>
>>
>> Um, but how many DB names have an "=" in them at all?
>>
>> Basically what this proposal is about is migrating from separated
>> dbname/user/host/port/etc parameters to a unified conninfo parameter.
>> That seems to me like a good long-term objective, and so I'm willing
>> to break a few eggs on the way to the omelet, as long as we're not
>> breaking any very likely usages.
>>
>> So: who here has a database with "=" in the name?  And hands up if
>> you've got a database whose name begins with "conn:"?
>>
>> I'm betting zero response rate on both of those, so see no reason to
>> contort the long-term definition for a very marginal difference in
>> the extent of backwards compatibility ...
>>
>>
>>
>
> I'm not sure -hackers is the most representative group to poll regarding
> dbnames in use ...
>
> Anyway, if I understand your current position, the only change needed to
> my current patch would be that if we fail to parse a dbname parameter
> that contains an = we simply fail at that point, rather than retrying it
> as a straight database name.
>
> I'm OK with that.
>


Here's the patch for what I think is the consensus position. If there's no
objection I will apply this and document it.

cheers

andrew

Attachment: dsnpatch
Description: Binary data

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

Reply via email to