Re: Cleaning up the INET/CIDR mess

This is exactly what I had in mind:
split the types    zero out the bits going to cidrno change going to inetmake functions take inet, which as not cast
change

---------------------------------------------------------------------------

Tom Lane wrote:
> We've had previous discussions about how the distinction between INET
> and CIDR isn't very well thought out, for instance
> http://archives.postgresql.org/pgsql-hackers/2005-01/msg01021.php
> http://archives.postgresql.org/pgsql-hackers/2006-01/msg00233.php
> 
> The basic problem is that the code is schizophrenic about whether these
> types are "the same" or not.  The fact that we have implicit binary
> (no function) coercions in both directions makes them effectively the
> same, so why are there two different type names in the catalogs?
> On the other hand, if they should be different (and they definitely
> have different I/O behavior), this coercion behavior is wrong.  Also,
> if they are different types, it's redundant to have a flag inside the
> data structure saying which type a particular value is.
> 
> After some consideration I've come to the conclusion that we really do
> want them to be separate types: the I/O behavior is settled (after quite
> some long discussions) and we don't want to change it, so we can't merge
> them into one type.  That leads to the following proposals:
> 
> Remove the internal is_cidr flag; it's a waste of space.  (It doesn't
> actually cost anything today, because of alignment considerations, but
> it would cost 2 bytes if we implement the proposed 2-byte-length-word
> variant datum format.)  Even more to the point, the presence of the
> flag has encouraged the sort of sloppy thinking and coding that got us
> into this mess.  Whether it's an INET or a CIDR should be totally
> determined by the SQL type system.
> 
> Without the flag, it's okay for cidr-to-inet to be a binary-compatible (no
> function) conversion.  However, inet-to-cidr has to either zero out bits
> to the right of the netmask, or error out if any are set.  Joachim Wieland
> posted a patch that makes the coercion function just silently zero out any
> such bits.  That's OK with me, but does anyone want to argue for an error?
> (If we do make the coercion function raise error, then we'd probably need
> to provide a separate function that supports the bit-zeroing conversion.)
> 
> Currently, both directions of cast are implicit, but that is a bad idea.
> I propose keeping cidr-to-inet as implicit but making inet-to-cidr an
> assignment cast.  This fits with the fact that inet can represent all
> values of cidr but not vice versa (compare int4 and int8).
> 
> Given the implicit binary-compatible coercion, it's OK to have just a
> single function taking inet for any case where the function truly doesn't
> care if it's looking at inet or cidr input.  For the cases where the code
> currently pays attention to is_cidr, we'd have to make two separate
> functions.  AFAICT that's only abbrev(inet) and text(inet) among the
> current functions.  Also, set_masklen(inet,integer) would have to come
> in two flavors since the output type should be the same as the input.
> 
> The relationship of cidr and inet would be a little bit like the relation
> between varchar and text.  For instance, varchar doesn't have any
> comparison operators of its own, but piggybacks on text's comparison
> operators, relying on the implicit cast from varchar to text to make this
> transparent to users.
> 
> One other point is what to do with the binary I/O functions (send/receive)
> for inet and cidr.  I think that we should continue to send the is_cidr
> flag byte for backwards-compatibility reasons.  On receive, we could
> either ignore that byte entirely, or insist that it match the expected
> datatype.  I'm inclined to ignore the byte but am willing to listen to
> arguments to raise an error instead.
> 
> Comments?
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073