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

From Josh Berkus
Subject Re: Patch: Implement failover on libpq connect level.
Date
Msg-id 562FB5EA.6010601@agliodbs.com
Whole thread Raw
In response to Proposal: Implement failover on libpq connect level.  (Victor Wagner <vitus@wagner.pp.ru>)
List pgsql-hackers
On 10/27/2015 01:42 AM, Shulgin, Oleksandr wrote:
> On Mon, Oct 26, 2015 at 10:02 PM, Christopher Browne <cbbrowne@gmail.com
> <mailto:cbbrowne@gmail.com>> wrote:
> 
> 
>     On 26 October 2015 at 16:25, Peter Eisentraut <peter_e@gmx.net
>     <mailto: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.

I'm good with this.  +1


-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: fortnight interval support
Next
From: Alvaro Herrera
Date:
Subject: Re: [DOCS] max_worker_processes on the standby