darcy@druid.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