Tommi Maekitalo wrote:
Users expect, that it works just after installation. But after following the discussion I think, that it is not so much a problem. I have 127.0.0.1 in my pg_hba.conf and when I set PGHOST to 127.0.0.1 it workes. If I set PGHOST to localhost, it resolves to ::1, wich don't match my pg_hba.conf-entry. The error message is somewhat clear and gives the user a good hint, where to look for.With the patch I submitted yesterday it would just work out of the box and no error message. ISTM the default setting should do just that.
I don't like the idea of doing something special with loopback-interfaces. Loopback-interfaces are to test the network and tries to handle everything like normal networking.Have a look at the patch: http://archives.postgresql.org/pgsql-patches/2003-09/msg00010.php
The only "special" thing it does is in deciding if a connection matches the rule. Otherwise it is treated exactly the same as any other network connection.
Is it possible to ignore IPv6-entries in pg_hba.conf on non-IPv6-machines? Then we could uncomment IPv6 localhost connections by default. Or uncomment these entries just on IPv6-machines. But this needs modification of default pg_hba.conf depending on OS.
Ignoring entries is probably storing up trouble for yourself in the future. Say I mistype "192.168:1.1" on an IP4 only machine and it is silently ignored?
Commenting out / uncommenting entries is problematic. The only sane time would be to do it at initdb time, ISTM. But what if IP6 is turned on after you run initdb? BOOM no work. With my patch you would keep working happily :-)
I'm done arguing about this - I'll leave it up to the committers to decide what they want to do and move on to something else.
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
