Hello!
>>> Well, it would obviously be better if PG could figure out it was safe,
>>> but I'm not sure there's a general case where it is. You can see it's OK
>>> because you know there's only one row in your SELECT result-set.
>
>> I think, it's OK because NULL can be compared with anything
>> with predictable result and no additional information about
>> types is necessary.
>> Is it correct vision?
>
>The backend doesn't really distinguish NULL from 'foo' (or untyped
>string literals in general) when making datatype decisions.
I think when PG is about to compare object of known type and known
value (it is 5 in my example) with object with unknown type
but known value or known null flag (it is null in my example) it is
high time to return 'false' instead of producing error.
As far as I understand, it is not about comparision only,
but about any operation.
I really believe NULLs are special here.
Of course I am a complete stranger and unaware of PostgreSQL internals
so what I am saying may contradict with some basical concepts. Looks like
it does since according to Tom, PostgreSQL does not treat null literals
in special way :(
Thanks.
--
Best regards
Ilja Golshtein
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
