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

>
> Thus spake Taral
> > > My guess is that maybe this should not be fixed in the individual
> > > datatypes at all; instead the generic function and operator code should
> > > be modified so that if any input value is NULL, then NULL is returned as
> > > the result without ever calling the datatype-specific code.
> >
> > AFAICT, the function code returns blank when the input is NULL, regardless
> > of the function definition... this came up before when someone tried to
> > extend the functions and found that func(NULL) called func, but disregarded
> > the return value...
>
> 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?

    I know that the function manager interface is  damned  stupid
    in  the  case of NULL's. Some of the interface functions pass
    isNull as in/out value and some do not. And the in value only
    tells if any of the arguments are NULL, not which of them. It
    hit me when building PL/pgSQL and PL/Tcl.

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


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #