Re: [HACKERS] A small problem with the new inet and cidr types

Thus spake Jan Wieck
> > Well that sure fits with my observations.  Sure seems wrong though.  We
> > should either use the return value or don't call the function in the
> > first place.  I vote for the latter even though I have spent the time
> > fixing inet.  It seems like the proper method.
> 
>     Not  calling  a  function  if  one of it's arguments is NULL?
>     Isn't NULL a legal value?

Sure but what is the reasonable thing to do if we perform a function
on a null?  Let's take the inet/cidr functions that started this.  If
i is a null field then these seem reasonable conversions.
 host(i) ==>  null network(i) ==> null broadcast(i) ==> null

...etc.

There may be cases where a function of a null is not null as some people
have pointed out but so far no one has come up with a practical example.

I suggested that the actual return value could depend on the return
type.  The only reason I suggested that was for the case of boolean
returns.  I see some merit in being able to decide in my select whether
or not to include rows where one or more operators is null but even
there it is probably of marginal utility.  If it is absolutely essential
to display every row then you can always constrain the field to NOT
NULL and use a marker value for null.

>     Let's redesign the function call interface  and  define  that
>     any  function  has  to handle NULL arguments properly. Yes, I
>     know what that means :-).

Well, let's hurry up and decide this so I know whether or not to
clean out my local patches to inet/cidr.  :-)

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.