We do not need pg_promote_v4_to_v6_addr/mask

We have some code in the server that attempts to match IPv4 address
entries in pg_hba.conf to incoming connections that are in IPv6 protocol
but have addresses in the range ::ffff:xxxx:xxxx (the IPv4-in-IPv6
subrange). As revealed by today's bug report from Hugo Osvaldo Barrera,
this code has been broken since commit f3aec2c7f51904e7 (shipped in 9.0),
as a result of sloppiness with a memcpy() source address. How is it that
nobody noticed?

Experimentation with a RHEL6 box says that at least on Linux kernels,
such cases never arise because the kernel will not report such an address
to the postmaster. You can ask to connect with an address like that,
viz "psql -h ::ffff:7f00:0001 ..." but what the kernel will tell the
postmaster is the client address is IPv4-style 127.0.0.1.

It's certainly possible that on other platforms there is a visible
distinction between ::ffff:7f00:0001 and 127.0.0.1, but the lack of field
complaints about this bug suggests that there isn't.

Moreover: suppose that on hypothetical platform X the kernel does report
such client addresses differently. Anybody on such a platform who's used
both types of client addresses with any 9.x release must have ended up
making different pg_hba.conf entries for the two cases. It's not
impossible that they chose to make the entries meaningfully different;
in which case they will not thank us for "fixing" the code so that the
distinction vanishes again. If your platform thinks these are different
addresses then you probably do too.

In short, then, I'm having second thoughts about the quick-hack patch
I committed earlier to fix the memcpy thinko. On platforms where it has
any effect at all, that effect will be to make a subtle and perhaps
security-relevant change to the interpretation of pg_hba.conf entries,
changing what the postmaster has treated them as meaning since 9.0.0.
That doesn't sound like the kind of thing we want to do in minor releases.

Therefore, I now think what we ought to do, both in HEAD and in the back
branches, is rip out the "#ifdef HAVE_IPV6" stanza in check_ip(), delete
pg_promote_v4_to_v6_addr and pg_promote_v4_to_v6_mask which will thereby
become unused, and remove the single sentence in the manual that claims
that IPv4-in-IPv6 connections will match IPv4 pg_hba.conf entries. This
amounts to accepting our behavior since 9.0 as being correct. If there
was ever a live need for the older behavior, its time has evidently
passed.

regards, tom lane