Re: [HACKERS] List of hostaddrs not supported

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: [HACKERS] List of hostaddrs not supported
Дата
Msg-id CAKFQuwY022Tr_E6BYKKEETuZSLhi0psXjU2JSPegYJ4NO=ZSZw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] List of hostaddrs not supported  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] List of hostaddrs not supported  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
On Thu, Jun 8, 2017 at 8:18 AM, Robert Haas <robertmhaas@gmail.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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] strange error message from slave when connection tomaster cannot be established
Следующее
От: "Regina Obe"
Дата:
Сообщение: Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity