Re: Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

I am just wondering, why "localhost" entry in /etc/hosts is editable
and why 127.0.0.1 not fixed with loopback interface?
should you agree with that we should submit a patch to kernel to
resolve "localhost" to 127.0.0.1 statically need no entry in
/etc/hosts and loopback interface bind to 127.0.0.1 not changeable?
If your answer is NO.
Why you give me this option to configure /etc/hosts or loopback
interface as well as deprive my option which hostname or IP for
statistics_collector to listen on?
Why operating system designed flexible and database system wrote in hard-coding?

Hard-coding is even worse than broken configuration:
1."broken configuration" is still configurable, that is the problem
could be fixed WITHIN the system.
2.hard-coding is NOT configurable, that is the problem must be aided
from OUTSIDE of the system to workaround.

configurable is just better than NOT configurable.
So, why we did no work to make things better, whereas wasting time to
insist hard-coding almost always right?

On Thu, Oct 27, 2011 at 14:42, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> BTW, do we have anything in place to stop any user on the same host to
>> send bogus stat messages to the stats collector?
>
> Yes.  Use of the connect() call is supposed to guarantee that we will
> only receive packets originating from our own socket address.
>
> As far as the original topic goes, I agree that it seems rather
> pointless to worry about systems that fail to resolve "localhost".
> Doing so is required by relevant RFCs, eg
> http://www.faqs.org/rfcs/bcp/bcp32.html
> (That's probably not the only one, it's just the first hit I found
> while searching the RFC archives.)
>
> And, given that we've been doing it this way since 2001 without
> previous complaints, the number of systems that fail to do it
> must be pretty small.
>
>                        regards, tom lane
>