On Thu, Sep 3, 2015 at 10:56:42AM -0400, Robert Haas wrote:
> The amount of opposition to this feature is remarkable considering
> that it's available in Oracle, SQL Server, MongoDB, Cassandra, and
> MySQL. See for example:
>
> http://docs.mongodb.org/manual/reference/connection-string/
> https://datastax.github.io/python-driver/getting_started.html
>
> This is a small patch with minimal to no downside implementing a
> feature that is present in most or all of the major competing
> products. We're really doing ourselves a disservice if we reject it.
> I think it would be far better to progress to talking about what
> design we'd be comfortable with, rather than kidding ourselves that a
> feature that everyone else has and which somebody has taken the time
> to implement (thus, obviously it has value for them) and which has
> been discussed to general approval at PGCon developer meetings and
> which has been endorsed on this thread by three committers is somehow
> something that nobody really needs. Seriously?
As much as I like to disagree with Robert, I can't in this case. ;-)
It is annoying for less capable database to say they have high
availability when that just involves having a client library that can
connect to multiple hosts. Yes, we can do this in DNS, but that is all
happening at a different layer.
Now, the counter-argument is that this is the wrong layer to do it, and
we will end up adding tons of configurations variables to libpq to
control this.
We are clearly not adding this just because JDBC has it --- we are
adding it because it allows for more complex server configurations.
Could this ability be more powerfully done with DNS or a connection
pooler, yes, but not everyone wants that complexity. For me, this libpq
change has a simple user API with a small amount of code change that
give us a simple solution to a common problem.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
