Re: Cleaning up the INET/CIDR mess - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Cleaning up the INET/CIDR mess
Date
Msg-id 24556.1138311447@sss.pgh.pa.us
Whole thread Raw
In response to Re: Cleaning up the INET/CIDR mess  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Cleaning up the INET/CIDR mess  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> 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?

> Zero the bits if it's an explicit cast, raise an error if not.

I know there's precedent for such behavior in the SQL spec, but it
always seemed pretty ugly to me :-(.  The patch-as-committed just
silently zeroes the bits during any inet->cidr cast.  I'll change it
if there's consensus that that's a bad idea, but I don't really see
a reason to.

BTW, there is another case I came across that wasn't discussed before:
if you do set_masklen() on a cidr value that reduces the netmask length,
there are the same options of either zeroing the excess bits or
complaining if any aren't zero.  I've got that doing the zeroing too.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: -X flag in pg_dump
Next
From: Bruce Momjian
Date:
Subject: Re: Cleaning up the INET/CIDR mess