Re: Problem with CIDR data type restrictions - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Problem with CIDR data type restrictions
Date
Msg-id 200410141926.i9EJQd600889@candle.pha.pa.us
Whole thread Raw
In response to Re: Problem with CIDR data type restrictions  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Added to TODO:
* Prevent inet cast to cidr if the unmasked bits are not zero, or  zero bits


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

Andrew Dunstan wrote:
> 
> 
> Tom Lane wrote:
> 
> >Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >  
> >
> >>Not sure how serious this is since we have gotten few complaints about
> >>it but clearly it should be fixed.
> >>    
> >>
> >
> >Personally I'm inclined to leave it for 8.1.  The inet/cidr code is
> >really designed around the assumption that these datatypes are
> >interchangeable, and I suspect that enforcing a stronger distinction
> >will actually take much more wide-ranging changes than just this.
> >Do all of the functions on inet/cidr take care to deliver a value that
> >is both correctly marked and declared as the correct type?  I doubt it.
> >It needs some thought not just a band-aid ...
> >
> >
> >  
> >
> 
> Yeah.
> 
> I am not sure I understand the intention, but I should have thought 
> there was a good case for clearing the bits past the mask on conversion 
> from either text or inet, rather than rejecting or invalidly copying.
> 
> As you say, it needs some thought.
> 
> cheers
> 
> andrew
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
> 

--  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
 


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: plperl Safe restrictions
Next
From: Jon Jensen
Date:
Subject: Re: plperl Safe restrictions