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(at)debis(dot)com (Jan Wieck) #