Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> probably be better to mark the Const node as having type UNKNOWN instead
>> of type 0 (but make_const is not the only place that makes null
>> constants this way! we'd need to find all the others...). But I am not
>> sure whether ParseFuncOrColumn would then do the right thing in terms of
>> resolving the type of the function; for that matter I'm not real sure
>> what the right thing for it to do is.
>> Thomas, this stuff is mostly your bailiwick; what do you think?
> My recollection is that UNKNOWN usually applies to strings of
> unspecified type, while "0" applies to NULL fields. I can put this on
> my list to look at later.
OK, but after mulling it over it seems that UNKNOWN is pretty much what
we want for an explicit null constant. If you want to consider NULL
as having a type different from UNKNOWN, then most of the places that
currently check for UNKNOWN would have to check for both, no?
> Another side issue; any function called with a null parameter will
> actually not get called at all! Postgres assumes that a function
> called with null must return null, so doesn't bother calling the
> routine...
Actually, it's even sillier than that: the function *is* called, but
then the OR of the input values' nullflags is attached to the output,
so you get back a null no matter what the function did. (This is why
all the functions that take pass-by-ref args have to be careful about
getting null pointers.)
In any case, I hope to see that fixed before 6.6/7.0/whatever our
next release is. So we do need a fix for the parser issue.
regards, tom lane
