Tom Lane wrote:
>Shachar Shemesh <psql@shemesh.biz> writes:
>
>
>>Tom Lane wrote:
>>
>>
>>>Yes, it can cast to varchar, but that doesn't help because there are no
>>>varchar operators ;-). To resolve the operator, it has to promote both
>>>sides to text, and you didn't offer a cast to text.
>>>
>>>
>>>
>>I don't get it.
>>
>>
>
>When we look to see whether we can cast from type X to type Y, we look
>to see whether there is a pg_cast entry from type X to type Y. We do
>not look to see if we could get there by casting X to some other type Z
>and thence to Y (much less more-than-2-step sequences). There are a
>number of good reasons for this, but I'll just mention speed and
>surprise factors. Doing so would make for an exponential increase in
>the number of potential cast paths, thereby probably paralyzing the
>operator selection code instead of making it more useful. (Too many
>alternatives are as bad as none.)
>
> regards, tom lane
>
>
That I got.
What I don't understand is this. The cast from varchar to text is a
no-function one. I.e. - they are defined to be memory-represented the
same. If that is the case, one would expect them to also share the input
and ouput functions. When looking at the catalog, however, it appears
that textin is used to input text, while varcharin is used for varchars.
Did I miss anything here?
It gets wierder. The binary receive function for varchar (varcharrecv)
is different than the one for text (textrecv), but the C implementation
of the former simply calls the C implementation of the later. Why not
define them to be the same at the SQL level?
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/