"Ilja Golshtein" <ilejn@yandex.ru> writes:
>> 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. If we
were to change the behavior of
select 1 where 5 in (select null)
at all, it would undoubtedly be to treat it as
select 1 where 5 in (select null::text)
because TEXT is the default resolution for UNKNOWN in every other
case where we force a choice to be made. But this is not what you
want for your example, and in general it would probably break as
many cases as it fixed. So I'm inclined to leave it as-is ---
an error message is probably better than a surprising silent choice.
My recommendation is to cast the NULL to the right type explicitly.
regards, tom lane