Definitional issue for INET types - Mailing list pgsql-hackers

From Tom Lane
Subject Definitional issue for INET types
Date
Msg-id 14929.950772313@sss.pgh.pa.us
Whole thread Raw
Responses Re: [HACKERS] Definitional issue for INET types  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
List pgsql-hackers
I tried fixing some of the known problems with comparison of INET values
(cf. thread "uniqueness not always correct" on 11/11/99, among others),
and was surprised to discover that my changes affected the results of
the inet regress test.  Specifically, the regress test exercises all the
inet comparison operators on the two data values'10.1.2.3/8'::inet     '10.0.0.0/32'::cidr
The old code believes that the first of these is greater, while my
revised code thinks the second is greater.

Now, my understanding of things is that '10.1.2.3/8' is just an
unreasonably verbose way of writing '10/8', because if you write /8
you are saying that only the first 8 bits mean anything.  So it seems
to me that we are really comparing '10/8' and '10.0.0.0/32', and the
former should be considered the lesser in the same way that 'ab'
comes before 'abc' in dictionaries.

Is the regress test's expected output wrong, or have I missed
something?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: [HACKERS] ERROR: Unable to identify an operator '=' for types 'numeric' and 'float8'
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Almost there on column aliases