Re: [HACKERS] A small problem with the new inet and cidr types - Mailing list pgsql-hackers

From darcy@druid.net (D'Arcy J.M. Cain)
Subject Re: [HACKERS] A small problem with the new inet and cidr types
Date
Msg-id m0zaPrG-0000eRC@druid.net
Whole thread Raw
In response to RE: [HACKERS] A small problem with the new inet and cidr types  ("Taral" <taral@mail.utexas.edu>)
Responses Re: [HACKERS] A small problem with the new inet and cidr types
List pgsql-hackers
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.

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


pgsql-hackers by date:

Previous
From: darcy@druid.net (D'Arcy J.M. Cain)
Date:
Subject: Re: [HACKERS] A small problem with the new inet and cidr types
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] A small problem with the new inet and cidr types