Re: [HACKERS] A small problem with the new inet and cidr types

darcy(at)druid(dot)net (D'Arcy J.M. Cain) writes:
> 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.

In fact they would *have* to be implemented as generics. If we tried
to implement them at the type-specific level, then we'd have to assign
specific types to the input and output values --- in other words, we'd
need a separate implementation for every possible combination of input
types.

The question at hand is whether any ordinary type-specific operators
or functions need to be non-strict (ie, capable of returning a non-NULL
output given one or more NULL inputs). Before we go to the trouble
of looking at/fixing every single type-specific operator or function
routine in the system, I'd like to see some concrete examples why
just turning off the spigot at the type-independent function dispatch
routine isn't good enough.

NOTE: aggregates definitely must be non-strict; I don't want SUM()
to come back with a NULL if I happen to include a NULL in its inputs.
But there are a lot fewer aggregate functions to look at than plain
old scalar functions.

regards, tom lane