On 06/08/2017 06:18 PM, Robert Haas wrote:
On Thu, Jun 8, 2017 at 10:50 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:Robert Haas <robertmh...@gmail.com> writes:It doesn't seem like a problem to me if somebody else wants to extend it to hostaddr, though. Whether that change belongs in v10 or v11 is debatable. I would object to adding this as an open item with me as the owner because doesn't seem to me to be a must-fix issue, but I don't mind someone else doing the work.If you want to define multiple-hostaddrs as a future feature, that seems fine, but I think Heikki is describing actual bugs. The minimum that I think needs to be done for v10 is to make libpq reject a hostaddr string with the wrong number of entries (either different from the host list, or different from 1).Whatever you put in the hostaddr field - or any field other than host and port - is one entry. There is no notion of a list of entries in any other field, and no attempt to split any other field on a comma or any other symbol. The fact that ::1,::1 looks to you like two entries rather than a single malformed entry is just a misunderstanding on your part, just like you'd be wrong if you thought that password=foo,bar is a list of passwords rather than a password containing a comma. I think the argument is about whether I made the right decision when I scoped the feature, not about whether there's a defect in the implementation.
Right. I think it's a usability fail as it is; it certainly fooled me. We could make the error messages and documentation more clear. But even better to allow multiple host addresses, so that it works as you'd expect.
I understand the slippery-slope argument that you might also want to have different usernames etc. for different hosts, but it's confusing that specifying a hostaddr changes the way the host-argument is interpreted. In the worst case, if we let that stand, someone might actually start to depend on that behavior. The other options don't have that issue. And hostaddr is much more closely tied to specifying the target to connect to, like host and port are.
I propose the attached patch, to allow a comma-separated list of hostaddr's. It includes some refactoring of the code to parse comma-separated lists, as it was getting a bit repetitive. It also fixes a couple of minor issues in error messages, see commit message.
The patch doesn't include docs changes yet. I think we should add a new sub-section, at the same level as the "33.1.1.1. Keyword/Value Connection Strings" and "33.1.1.2. Connection URIs" sub-sections, to explain some of the details we've discussed here. Something like:
--- 33.1.1.3 Specifying Multiple HostsIt is possible to specify multiple hosts to connect to, so that they are tried in the order given. In the Keyword/Value syntax, the host, hostaddr, and port options accept a comma-separated list of values. The same number of elements should be given in each option, such that e.g. the first hostaddr corresponds to the first host name, the second hostaddr corresponds to the second host name, and so forth. As an exception, if only one port is specified, it applies to all the hosts.
In the connection URI syntax, you can list multiple host:port pairs separated by commas, in the host component of the URI.
A single hostname can also translate to multiple network addresses. A common example of this is that a host can have both an IPv4 and an IPv6 address.
When multiple hosts are specified, or when a single hostname is translated to multiple addresses, all the hosts and addresses will be tried in order, until one succeeds. If none of the hosts can be reached, the connection fails. If a connection is established successfully, but authentication fails, the remaining hosts in the list are not tried.
If a password file is used, you can have different passwords for different hosts. All the other connection options are the same for every host, it is not possible to e.g. specify a different username for different hosts.
--- - Heikki
0001-Allow-multiple-hostaddrs-to-go-with-multiple-hostnam.patch
Description: invalid/octet-stream
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
