Re: Summary: what to do about INET/CIDR

Peter Eisentraut <peter_e@gmx.net> writes:
> Inet is supposed to be host address, with optional network specification.

Agreed.  As such, it probably should always display all 4 octets
regardless of the maskwidth.  It doesn't do that at the moment:

regression=# select '127.0.0.1/8'::inet;?column?
----------127.0/8
(1 row)

This is clearly bad.  I will change it to produce '127.0.0.1/8',
unless someone has a better idea.

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

> * inet output is broken => 127.0.0.1/8

See above.

> * no cast function to "text" available

I don't see much point in solving that issue on a one-datatype-at-a-time
basis.  Sooner or later we should fix things so that the datatype I/O
conversion functions can be invoked safely in expressions.

> * equality/distinctness is broken in certain cases => select
> '10.0.0.1/27'::inet='10.0.0.2/27'::inet; returns true

This is now fixed.

> * operator commutators and negators are incorrect

Fixed.

> * ouput functions apparently null-terminate their result => select
> host('10.0.0.1')='10.0.0.1'; returns false

Not sure what that has to do with output functions, but I get 'true'
now.

> * comparing inet and cidr is not well defined

Perhaps not.  There was a whole lot of argument about that point,
and it didn't seem to me that we came to any real agreement.

> * should '127.0.0.1/24'::cidr fail?

Looks like we've resolved that as "yes".

There are still unresolved issues about whether inet and cidr should be
considered binary-equivalent, what network_sup/sub mean when comparing
inet and cidr, whether we are missing any important functions, etc.
I'm not hoping to get these resolved for 7.1, considering we are nearly
at beta stage and don't even have a complete proposal for what to do.
I'm satisfied for the moment with having eliminated the failure to
compare all bits of the values, which led to bogus equality results
and consequent malfunction of indexes.
        regards, tom lane