On Fri, Nov 6, 2015 at 10:38 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Craig Ringer wrote: >> On 6 November 2015 at 13:34, Robert Haas <robertmh...@gmail.com> wrote: >> >> >> 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. >> >> This makes me think that trying to wedge this into the current API >> using a funky connection string format might be a mistake. >> >> Lots of these issues would go away if you could provide more than just >> a connstring. > > Yes, I agree. I wonder if the failover aspect couldn't be better > covered by something more powerful than a single URI, such as the > service file format. Maybe just allow the contents of a service file to > be passed as a "connection string", so that the application/environment > can continue to maintain the connection info as a string somewhere > instead of having to have an actual file.
This gets pretty far from the concept of a connection string, which is supposed to be a sort of universal format for telling anything PostgreSQL how to find the database server. For example, psql accepts a connection string, but you wouldn't want to have to pass the entire contents of a file, newlines and all, as a command-line argument. Now, we could design some kind of new connection string format that would work, like: psql 'alternatives failovertime=1 (host=192.168.10.49 user=rhaas) (host=192.168.10.52 user=bob)' There are a couple of problems with this. One, it can't be parsed anything like a normal connection string. Lots of software will have to be rewritten to use whatever parser we come up with for the new format. Two, it's nothing like the existing JDBC syntax that already does more or less what people want here. Three, I think that implementing it is likely to be an extraordinarily large project. The whole data structure that libpq uses to store a parsed connection string probably needs to change in fairly major ways. So, I really wonder why we're not happy with the ability to substitute out just the host and IP. http://www.postgresql.org/message-id/4dfa5a86.9030...@acm.org https://jdbc.postgresql.org/documentation/94/connect.html (bottom of page) Yes, it's possible that some people might need to change some other parameter when the host or IP changes. But those people aren't prohibited from writing their own function that tries to connect to multiple PostgreSQL servers one after the other using any system they'd like. I don't think we really need to cater to every possible use case in core. The JDBC feature has been out for several years and people seem to like it OK - the fact that we can think of things it doesn't do doesn't make it a bad idea. I'd rather have a feature that can do 95% of what people want in the real world next month than 99% of what people want in 2019, and I'm starting to think we're setting the bar awfully high. -- 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
