Re: Patch: Implement failover on libpq connect level. - Mailing list pgsql-hackers

From Shulgin, Oleksandr
Subject Re: Patch: Implement failover on libpq connect level.
Date
Msg-id CACACo5Sno_rvor892t-rxVtA+19VYXZD1JR=8_orWm-6-0xKCQ@mail.gmail.com
Whole thread Raw
In response to Re: Patch: Implement failover on libpq connect level.  (Christopher Browne <cbbrowne@gmail.com>)
List pgsql-hackers
On Mon, Oct 26, 2015 at 10:02 PM, Christopher Browne <cbbrowne@gmail.com> wrote:

On 26 October 2015 at 16:25, Peter Eisentraut <peter_e@gmx.net> wrote:
On 10/14/15 6:41 AM, Victor Wagner wrote:
> 1. It is allowed to specify several hosts in the connect string, either
> in URL-style (separated by comma) or in param=value form (several host
> parameters).

I'm not fond of having URLs that are not valid URLs according to the
applicable standards.  Because then they can't be parsed or composed by
standard libraries.

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.

I think you should just accept multiple URLs.

I'd give a "+1" on this...

As an area of new behaviour, I don't see a big problem with declining to
support every wee bit of libpq configuration, and instead requiring the
use of URLs.

Trying to put "multiplicities" into each parameter (and then considering
it at the pg_service level, too) is WAY more complicated, and for a
feature where it seems to me that it is pretty reasonable to have a
series of fully qualified URLs.

Specifying several URLs should be easier to understand, easier to
test, easier to code, and easier to keep from blowing up badly.

Setting aside all other concerns, have a +1 from me on that too.

--
Alex

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: TODO list updates
Next
From: rajan
Date:
Subject: Disabling START TRANSACTION for a SuperUser