From: | darcy(at)druid(dot)net (D'Arcy J(dot)M(dot) Cain) |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] A small problem with the new inet and cidr types |
Date: | 1998-11-02 18:06:38 |
Message-ID: | m0zaONC-0000eRC@druid.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at){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.
From | Date | Subject | |
---|---|---|---|
Next Message | Taral | 1998-11-02 18:31:23 | RE: [HACKERS] A small problem with the new inet and cidr types |
Previous Message | Thomas G. Lockhart | 1998-11-02 16:46:21 | Re: [HACKERS] A small problem with the new inet and cidr types |