Re: Old question - failed to find conversion function from "unknown"

From: "Ilja Golshtein" <ilejn(at)yandex(dot)ru>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Old question - failed to find conversion function from "unknown"
Date: 2005-07-19 15:01:05
Message-ID: 42DD15B1.000004.19702@mfront8.yandex.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-general

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

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2005-07-19 15:19:06 Re: Old question - failed to find conversion function from
Previous Message guly 2005-07-19 14:33:20 how to build vsftpd with pgsql pam

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2005-07-19 15:19:06 Re: Old question - failed to find conversion function from
Previous Message Scott Marlowe 2005-07-19 14:48:25 Re: index row size exceeds btree maximum, 2713 -