From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Victor Wagner <vitus(at)wagner(dot)pp(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch: Implement failover on libpq connect level. |
Date: | 2015-11-02 17:15:48 |
Message-ID: | 56379A44.9080609@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
On 10/30/15 9:26 AM, Robert Haas wrote:
> That's true, but doesn't allowing every parameter to be multiply
> specified greatly increase the implementation complexity for a pretty
> marginal benefit?
Well, the way I would have approached is that after all the parsing you
end up with a list of PQconninfoOption arrays and you you loop over that
list and call connectDBStart() until you have a connection that
satisfies you.
I see that the patch doesn't do that and it looks quite messy as a result.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2015-11-02 17:15:51 | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions |
Previous Message | Joe Conway | 2015-11-02 17:10:24 | Re: exposing pg_controldata and pg_config as functions |
From | Date | Subject | |
---|---|---|---|
Next Message | stallapp | 2015-11-03 13:23:17 | Problem in getting column names from DatabaseMetadata Object |
Previous Message | Josh Berkus | 2015-10-30 17:21:53 | Re: Patch: Implement failover on libpq connect level. |