Re: Old question - failed to find conversion function from "unknown" - Mailing list pgsql-general

From Tom Lane
Subject Re: Old question - failed to find conversion function from "unknown"
Date
Msg-id 23591.1121782655@sss.pgh.pa.us
Whole thread Raw
In response to Re: Old question - failed to find conversion function from "unknown"  ("Ilja Golshtein" <ilejn@yandex.ru>)
Responses Re: Old question - failed to find conversion function from "unknown"
List pgsql-general
"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

pgsql-general by date:

Previous
From: Alex Stapleton
Date:
Subject: Stored Procedures for Security
Next
From: Janning Vygen
Date:
Subject: Re: Changes to not deferred FK in 8.0.3 to 7.4?