That's true, but doesn't allowing every parameter to be multiply specified greatly increase the implementation complexity for a pretty marginal benefit?
Well, the way I would have approached is that after all the parsing you end up with a list of PQconninfoOption arrays and you you loop over that list and call connectDBStart() until you have a connection that satisfies you.
I see that the patch doesn't do that and it looks quite messy as a result.
There are some drawbacks with this approach
You are suggesting usage of two nested loops, instead of one straight loop - outer loop over the URLs in the connect string, inner loop over the IP addresses each URL resolves into. (This inner loop already presents there for several versions of the postgres).
You are suggesting that it should be possible to specify all options separately for each of the fallback hosts.
But some options control how next host should be choosen (i.e. use random order for load-balancing or sequential order for high availability), so they should be specified only once per connect string.
Some other options are connection level rather then node-level (i.e. if you are using replication mode of the connection, there is no sense to specify it for one host and not specify for other). These options should be better specified such way, that it would be not possible to use conflicting values.
Third category of options are specified per-cluster much more often than per node. But are quite often changed from compiled in default. Typically there are authentication credentials (even you use trigger-based replication, user information would probably be replicated), database name (if you use WAL-level replication), client encoding (which depends on more on the client than on server), etc.
It would be pain if we would need specify them for each host separately. Syntax, implemented in the my patch allows even to specify nonstandard-port once for all hosts (using port= parameter in the query string) and override it for particular host in the list using colon syntax.
- Last, but not least. There is more than one postgresql client implementation. Apart of libpq we have jdbc, native GO language client etc. And I think that maintaining compatibility of the connect string between them is good thing. So, I've modelled syntax of multihost feature in the libpq URL-style syntax after jdbc syntax.