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.



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

Reply via email to