Re: Cleaning up the INET/CIDR mess

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Cleaning up the INET/CIDR mess
Date: 2006-01-26 21:37:27
Message-ID: 24556.1138311447@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-01-26 21:41:32 Re: VACUUM Question
Previous Message Bruce Momjian 2006-01-26 21:31:09 Re: -X flag in pg_dump