On 30 October 2015 at 09:26, Robert Haas <robertmh...@gmail.com> wrote: > > On Thu, Oct 29, 2015 at 8:29 PM, Peter Eisentraut <pete...@gmx.net> wrote: > > On 10/28/15 4:18 AM, Victor Wagner wrote: > >> On Mon, 26 Oct 2015 16:25:57 -0400 > >> Peter Eisentraut <pete...@gmx.net> wrote: > >> > >>> Also, this assumes that all the components other than host and port > >>> are the same. Earlier there was a discussion about why the ports > >>> would ever need to be different. Well, why can't the database names > >>> be different? I could have use for that. > >> > >> Because of way postgresql replication is implemented. > > > > There are multiple types of PostgreSQL replication, and there will be > > others in the future. > > That's true, but doesn't allowing every parameter to be multiply > specified greatly increase the implementation complexity for a pretty > marginal benefit? I think host and IP would hit 98% of the use cases > here.
I think it makes the feature WORSE. I am getting more and more convinced that the Correct Solution is for this feature to be handled by submitting multiple URIs, and my argument isn't even based on any aspects of implementation complexity. Take as example the case where I have two database servers I want to be considered. a) Database with URI postgresql://cbbro...@server-a.example.info:5432/my-first-database b) Database with URL postgresql://rob...@server-b.example.info:7032/my-second-database With all the "per-variable multiplicities", this would turn into a combinatorial explosion of combinations, some 2^4, or 16 possible servers, some of which likely don't exist, and others of which aren't proper (e.g. - trying to connect to database a) using robert's credentials). Possibly some of those combinations are outright improper. I'm not going to claim it's terribly wise to be doing the cross-credential bit; I'd think it likely to be rather dumb for the application to use one user when connecting to one database and another when connecting to another. But the notion of it being nondeterministic is just awful. I head back to... "the way OpenLDAP does this"... They let you specify multiple LDAP servers... ldap://server1.example.info:389 ldap://server2.example.info:389 where URIs are separated by whitespace. Seems like Best Goodness for Postgres to do something analogous... postgresql://cbbro...@server-a.example.info:5432/my-first-database postgresql://rob...@server-b.example.info:7032/my-second-database Is it a bit long? Sure. But it is unambiguous, and requires *only* whitespace parsing to separate the URIs. I'd think it fine for Postgres to support this via multiple "-d" options; that would be about as good. That can cover 100% of cases, and I don't see it needing to interact specially with odd bits such as "was that a replication slot?" You can always choose to shoot yourself in the foot, but this doesn't spin the roulette for you... -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"