Ilja Golshtein wrote:
>>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?
Yes*, but you've not got a single NULL in your examples, you've got a
set of rows containing one unnamed column with an unspecified type. That
set happens to have only one row and that contains a NULL.
> I agree it's hard to proceed your query with UNION
> and some sort of error is reasonable here.
But from outside the brackets, they look the same.
What would happen ideally, is that PG would notice we have a single row
and column here and collapse this down to a single scalar value.
However, I'm not sure under what circumstances it can do so (or does),
or whether it is cost-effective.
[* Actually, I think NULLs are typed in SQL, which means you should be
able to get type violations. ]
--
Richard Huxton
Archonet Ltd
