Re: Summary: what to do about INET/CIDR - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Summary: what to do about INET/CIDR
Date
Msg-id Pine.LNX.4.21.0010272110500.838-100000@peter.localdomain
Whole thread Raw
In response to Summary: what to do about INET/CIDR  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane writes:

> 1.  A data value like '10.1.2.3/16' is a legal INET value (it implies
> the host 10.1.2.3 in the network 10.1/16) but not a legal CIDR value.
> Hence, cidr_in should reject such a value.  Up to now it hasn't.

Nod.

> 2.  We do not have a datatype corresponding strictly to a host address
> alone --- to store a plain address, use INET and let the mask width
> default to 32.  inet_out suppresses display of a "/32" netmask (whereas
> cidr_out does not).

Inet is supposed to be host address, with optional network specification.

I also have in my notes (some might have been fixed since):

* inet output is broken => 127.0.0.1/8
* no cast function to "text" available (what about host()?)
* equality/distinctness is broken in certain cases => select
'10.0.0.1/27'::inet='10.0.0.2/27'::inet; returns true
* operator commutators and negators are incorrect
* ouput functions apparently null-terminate their result => select
host('10.0.0.1')='10.0.0.1'; returns false
* comparing inet and cidr is not well defined
* should '127.0.0.1/24'::cidr fail?

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



pgsql-hackers by date:

Previous
From: teg@redhat.com (Trond Eivind Glomsrød)
Date:
Subject: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Next
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)