`inet` docs suggestion and possible bug report

[Nathan Long]

On https://www.postgresql.org/docs/current/datatype-net-types.html the
opening paragraph says:

> PostgreSQL offers data types to store IPv4, IPv6, and MAC addresses, as
shown in Table 8.21
.
It is better to use these types instead of plain text types to store
network addresses, because these types offer input error checking and
specialized operators and functions (see Section 9.12
).

At least in the case of `inet`, another reason is for accurate comparison.
IPv4 and IPv6 both have shorthand textual representations; eg `127.1` =
`127.1.0.0`. Text storage would consider these unequal.

I propose modifying the leading paragraph to say:

> PostgreSQL offers data types to store IPv4, IPv6, and MAC addresses, as
shown in Table 8.21
.
It is better to use these types instead of plain text types to store
network addresses, because these types offer input error checking,
**accurate comparison,** and specialized operators and functions (see
Section 9.12 ).

and appending a sentence to `8.9.1 inet` as follows:

> Because it stores an address in its canonical format, inet provides
reliable comparison between addresses. Both IPv4 and IPv6 have shorthand
formats which would compare as unequal if stored as plain text; for
example, `SELECT '127.1' = '127.1.0.0';` returns false, but `SELECT
':::127.0.0.1'::inet = ':::127.1'::inet;` returns true.

A possible bug report: As of I expected `SELECT '127.1'::inet =
'127.0.0.1'::inet;` to return true, but as of 16.6 the cast on the
shorthand format fails, even though it handles the IPV6-mapped equivalent.

-- Nathan

Re: `inet` docs suggestion and possible bug report

[Tom Lane]

Nathan Long  writes:
> At least in the case of `inet`, another reason is for accurate comparison.
> IPv4 and IPv6 both have shorthand textual representations; eg `127.1` =
> `127.1.0.0`. Text storage would consider these unequal.

I'm not sure how much we want to press that point, because AFAICS
the code we use does not have the same abbreviation rules you are
expecting.  Notably, it thinks '127.1' means 127.1.0.0.
(We lifted this logic from BIND 20+ years ago, so while it might
not entirely agree with practice elsewhere, it has a respectable
pedigree and I'm hesitant to mess with it.)

> A possible bug report: As of I expected `SELECT '127.1'::inet =
> '127.0.0.1'::inet;` to return true, but as of 16.6 the cast on the
> shorthand format fails, even though it handles the IPV6-mapped equivalent.

That seems to be falling foul of this restriction in inet_net_pton_ipv4:

/* Prefix length can default to /32 only if all four octets spec'd. */
if (bits == -1)
{
if (dst - odst == 4)
bits = 32;
else
goto enoent;
}

although if we relaxed that restriction it'd still fail at the next
bit,

/* If prefix length overspecifies mantissa, life is bad. */
if ((bits / 8) > (dst - odst))
goto enoent;

which is why '127.1/32'::inet also fails.

Maybe somebody should take a look at current BIND and see if they
redefined these rules.  Per our git log, we've not attempted to
sync this code with upstream since 2005.

regards, tom lane