On Thu, Nov 5, 2015 at 10:12 AM, Victor Wagner <vi...@wagner.pp.ru> wrote: > There are some drawbacks with this approach > > 1. 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).
This isn't really a problem. > 2. 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. But this seems like a point worthy of consideration. > 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. This, too. > 3. 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. Also this. I'm not sure what the right decision is here - I can see both sides of it to some degree. But I think your points deserve to be taken seriously. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers