On Thu, Sep 3, 2015 at 12:57 PM, Shulgin, Oleksandr <oleksandr.shul...@zalando.de> wrote: > On Thu, Sep 3, 2015 at 6:02 PM, Robert Haas <robertmh...@gmail.com> wrote: >> Maybe someday we should have all that, but I think for right now >> that's complicating things unnecessarily. I think the best proposal >> so far is to allow the host=X option to be repeated multiple times. >> If you repeat the host=X option N times, you can also repeat the >> port=X option exactly N times, or else you can specify it just once. >> Done. > > But this already breaks backwards-compatibility with any clients who belief > that whatever value specified the latest takes precedence. I'm not arguing > that there are such use cases in the wild or that it's entirely sane thing > to do, but still.
Yep. If we care about backward compatibility, there can be a new option that must be specified to get the new behavior. We can also decide not to care about this case. > More importantly, this will break any code that tries to parse the conninfo > string and produce a hashmap from it for modification. That is true, but I am not sure I agree that it is important. Switch to a hashmap whose values are arrays. >> Alternatively, leave the host=X option alone and add a new option >> hostlist=X, allowing a comma-separated list of names or IPs, with each >> hostname or IP allowed an optional :port suffix. If host=X parameter >> is omitted or the connection to that machine fails, try everybody in >> the hostlist concurrently, or with some configurable (and presumably >> short) delay between one and then next. Again, done. > > The exact behavior in case of both host/port and hostlist are specified > becomes really tricky then. It's already tricky enough, if you recall the > service files -- how are they going to come into play here? It doesn't seem that tricky to me, but maybe I'm biased by having just invented it 5 minutes ago. > I believe the less there are implicit workings in the way libpq connects, > the better. I don't disagree with that as a general rule - only when it keeps us from implementing useful features. >>> Alternatively, change the rules for parsing the existing host=X >> parameter so that we split it on some separator that isn't a valid >> hostname character, and then strip off an optional :port syntax from >> each entry; that value, if present, overrides port=X for that entry. > > It's tempting to use ':' as the separator here, but it's still valid for > directory names and host can be one in case of UN*X sockets. The directory name is only likely to contain : on Windows, and Windows doesn't support UNIX sockets. All of these objections seem pretty thin to me. I'd accept any of them as a reason for preferring one alternative over another, but I don't accept that the presence of a few problems of this magnitude means we should give up on the feature. It's a good enough feature that it is worth the possibility of slightly inconveniencing someone running in an unusual configuration. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
