Re: [HACKERS] List of hostaddrs not supported

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] List of hostaddrs not supported
Дата
Msg-id CA+TgmoZHuX1eTcExGjz-1WG61qQWPQomDXpeTCfOQ-UQUn5UfQ@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] List of hostaddrs not supported  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: [HACKERS] List of hostaddrs not supported  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Jun 8, 2017 at 4:36 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> So, this is all quite confusing. I think we should support a list of
> hostaddrs, to go with the list of hostnames. It seems like a strange
> omission. Looking at the archives, it was mentioned a few times when this
> was developed and reviewed, latest Takayuki Tsunakawa asked [1] the same
> question, but it was then forgotten about.

I didn't really forget about it; I just didn't think it seemed
important.  There seemed to be a danger of scope creep, too.  For
example, you could argue that multiplicity ought to also be permitted
for passwords.  The status quo is that you can use different passwords
for different hosts if you specify the password via your .pgpass file,
but not if you include it in the connection string, and somebody could
argue that's weird and inconsistent.  But if you allow multiple
passwords then maybe you ought to also allow multiple usernames.  And
what do you do about the possibility that a password contains a
literal comma?  And if you allow a different password for each host,
maybe you ought to allow a different sslcert, too, for people not
using passwords to authenticate.  Maybe hostaddr is more
closely-related than any of that stuff, but I just made a judgement
call that host by itself was going to be a problem but host+port was
enough to make a credible minimal patch, and I didn't want to go
beyond what was absolutely required for fear of biting off more than I
could chew.

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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: [HACKERS] Does pg_upgrade really support "make installcheck"?