Re: `inet` docs suggestion and possible bug report

Nathan Long <hello(at)nathanmlong(dot)com> 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