From: | darcy(at)druid(dot)net (D'Arcy J(dot)M(dot) Cain) |
---|---|
To: | hannu(at)trust(dot)ee (Hannu Krosing) |
Cc: | jwieck(at)debis(dot)com, taral(at)mail(dot)utexas(dot)edu, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] A small problem with the new inet and cidr types |
Date: | 1998-11-03 13:53:16 |
Message-ID: | m0zagtY-0000eRC@druid.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thus spake Hannu Krosing
> D'Arcy J.M. Cain wrote:
> > There may be cases where a function of a null is not null as some people
> > have pointed out but so far no one has come up with a practical example.
>
> isnull(field)
>
> is_any_null(field1,field2,field3)
>
> are_all_nulls(field1,field2,field3)
>
> value_or_default(NULL,defaultvalue)
I meant in the specific type functions. These functions seem like they
can easily be handled at a higher level and still never call the type
function code. IOW, if these functions are considered useful, they
should be implemented at the function dispatch level.
That last one seems particularly useful to me and, in fact, could handle
the issue of requiring functions to handle nulls all by itself.
--
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 | D'Arcy J.M. Cain | 1998-11-03 14:06:38 | Re: [HACKERS] A small problem with the new inet and cidr typesg |
Previous Message | Hannu Krosing | 1998-11-03 13:09:12 | Re: [HACKERS] A small problem with the new inet and cidr types |