"Ilja Golshtein" <ilejn@xxxxxxxxx> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
