Wrong masklen in result of netmask()/hostmask()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Wrong masklen in result of netmask()/hostmask()
Date: 2003-12-01 04:06:55
Message-ID: 14966.1070251615@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Per this gripe:
http://archives.postgresql.org/pgsql-bugs/2003-11/msg00233.php
I think that the recent IPv6 changes made an undocumented and
un-agreed-to change in the semantics of netmask().

The previous behavior of netmask() was that it always delivered
a result with a masklen of 32. It seems to me that the obvious
extension of that for IPv6 is to deliver masklen of either 32
or 128 depending on whether the input is IPv4 or IPv6. The
actual behavior in 7.4 is that the masklen is the same as the
input value's, for example:

7.3:
regression=# select masklen(netmask('192.168.1.0/23'));
masklen
---------
32
(1 row)

7.4:
regression=# select masklen(netmask('192.168.1.0/23'));
masklen
---------
23
(1 row)

The previous behavior had been agreed to at one point:
http://archives.postgresql.org/pgsql-hackers/2000-10/msg01132.php
I can't find anyplace in the archives where the change was discussed
at all.

hostmask() was not in 7.3 so its behavior is a bit up for grabs,
but I think it ought to return the same masklen as netmask().

Comments?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-12-01 04:10:09 Re: [PATCH] Re: [pgsql-advocacy] Why READ ONLY transactions?
Previous Message Joe Conway 2003-12-01 00:23:00 Re: Was: Triggers, Stored Procedures, PHP