Heikki Linnakangas <hlinnakangas@vmware.com> writes:
>>>
>>> The second one is a self-contained fix, but the third one which is the
>>> actual patch depends on the second one, because it specifies the dbname
>>> keyword two times: first to parse the conninfo/URI, then to override any
>>> dbname provided by the user with "replication" pseudo-database name.
>>
>> Hmm. Should we backpatch the second patch? It sure seems like an
>> oversight rather than deliberate that you can't override dbname from the
>> connection string with a later dbname keyword. I'd say "yes".
>>
>> How about the third patch? Probably not; it was an oversight with the
>> connection URI patch that it could not be used in primary_conninfo, but
>> it's not a big deal in practice as you can always use a non-URI
>> connection string instead.
>
> Ok, committed the second patch to all stable branches, and the third
> patch to master.
>
> In the second patch, I added a sentence to the docs to mention that
> only the first "dbname" parameter is expanded. It's debatable if
> that's what we actually want. It would be handy to be able to merge
> multiple connection strings, by specifying multiple dbname
> parameters. But now the docs at least match the code, changing the
> behavior would be a bigger change.
>
> From the third patch, I removed the docs changes. It's necessary to
> say "connection string or URI" everywhere, the URI format is just one
> kind of a connection string. I also edited the code that builds the
> keyword/value array, to make it a bit more readable.
Yay, many thanks! :-)
--
Alex
