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 m0zaONC-0000eRC@druid.net
Whole thread Raw
In response to Re: [HACKERS] A small problem with the new inet and cidr types  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] A small problem with the new inet and cidr types
Re: [HACKERS] A small problem with the new inet and cidr types
List pgsql-hackers
Thus spake Tom Lane
> 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.

Could it be tied to the return type?  IOW, functions or operators
that return bool return FALSE, text return "", etc.

> There might be specific operators for which this is not the right
> behavior (although none spring to mind immediately).  In that case,
> I think the best bet would be to have a per-operator flag, defaulting
> to OFF, which could be turned on for those specific operators that are
> prepared to cope with null inputs.

Obviously that will have to wait for 6.5 since it requires an initdb
to add the field.  Do we want to wait that long?

-- 
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: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] A small problem with the new inet and cidr types
Next
From: "Taral"
Date:
Subject: RE: [HACKERS] A small problem with the new inet and cidr types