Andrew Dunstan <[EMAIL PROTECTED]> 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.
OK, having it comment out the line for the non-ip6 case seems safe enough. Having it add the line for the ip6 case would be more dangerous ISTM.
BTW, who if anyone is rewriting initdb in C? I presume we need that for windows so we are not dependent on having a working shell.
andrew
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
