Heikki Linnakangas <hlinnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
