From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TCP/IP with 7.4 beta2 broken? |
Date: | 2003-09-05 13:42:31 |
Message-ID: | 8898.1062769351@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> OK, now we are getting somewhere. I see that this would work. It's a bit
> ugly, though - with this plan the sample file in both CVS and the
> installation won't necessarily be what actually get put in place.
Well, like I said, it's not real pretty. But the same is already true
of postgresql.conf.sample --- initdb edits that. I don't see that
having it edit pg_hba.conf.sample too is so bad.
> What if some clever installer/administrator deliberately alters their
> installed sample file?
I don't think it would hurt them. The editing will consist of a sed
script to comment or uncomment the line containg ::1, it wouldn't touch
anything else.
> Could we get the configure script to do it instead, since it too should
> know about ip6 capability? (I guess then we'd have
> pg_hba.conf.sample.in). That strikes me as being a lot cleaner.
Bruce and I talked about that alternative too, but we felt that it made
more sense to keep the processing of pg_hba.conf.sample parallel to what
happens to postgresql.conf.sample. Further down the road we might need
initdb-time checks to decide what to do to the sample file, just as we
already need for postgresql.conf.sample.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-09-05 13:52:41 | Re: [PATCHES] Warning for missing createlang |
Previous Message | Jan Wieck | 2003-09-05 13:35:11 | Re: Stats Collector Error 7.4beta1 and 7.4beta2 |