Re: List of hostaddrs not supported

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: List of hostaddrs not supported
Date: 2017-06-08 15:39:06
Message-ID: CAKFQuwY022Tr_E6BYKKEETuZSLhi0psXjU2JSPegYJ4NO=ZSZw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 8, 2017 at 8:18 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> 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.
>
​[...]​

> 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.
>

Implementation comes into play if the scope decision stands.

​I have no immediate examples but it doesn't seem that we usually go to
great lengths to infer user intent and show hints based upon said
inference. But we also don't forbid doing so. So the question of whether
we should implement better error messages here seems to be in scope -
especially since we do allow for lists in some of the sibling fields.​

These are already failing so I'd agree that explicit rejection isn't
necessary - the question seems restricted to usability. Though I suppose
we need to consider whether there is any problem with the current setup if
indeed our intended separator is also an allowable character - i.e., do we
want to future-proof the syntax by requiring quotes now?

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Regina Obe 2017-06-08 15:57:49 Re: PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity
Previous Message Robert Haas 2017-06-08 15:19:47 Re: strange error message from slave when connection to master cannot be established