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
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 |