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

From Christopher Browne
Subject Re: Patch: Implement failover on libpq connect level.
Date
Msg-id CAFNqd5XXk+E+qxaNtB04RBpCQigUF=z0EJWDmUHpT0qMuM15SQ@mail.gmail.com
Whole thread Raw
In response to Re: Patch: Implement failover on libpq connect level.  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Patch: Implement failover on libpq connect level.
List pgsql-hackers

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.

I'll observe that this is the way that OpenLDAP supports specifying
multiple clients, so this technique is familiar in other contexts
where people are trying to accomplish the same kind of thing.
Sample docs, perhaps not authoritative, but useful enough...
<http://manpages.courier-mta.org/htmlman5/ldap.conf.5.html>
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: UTF-32 support in PostgreSQL ?
Next
From: José Luis Tallón
Date:
Subject: Re: pg_basebackup and replication slots