Re: [BUGS] Failure to coerce unknown type to specific type

Hello,

> > Very sorry for the trash..
> >
> > ===
> > Now I found a comment at just where I patched,
> >
> > > * XXX if the typinput function is not immutable, we really ought to
> > > * postpone evaluation of the function call until runtime. But there
> > > * is no way to represent a typinput function call as an expression
> > > * tree, because C-string values are not Datums. (XXX This *is*
> > > * possible as of 7.3, do we want to do it?)
> >
> > - Is it OK to *now* we can do this?
> > + Is it OK to regard that we can do this *now*?
> >
> >
> In this patch or a different one? Does this comment have anything to do
> with the concern of this thread?

The comment cieted above is in the PostgreSQL source file. The
reason why implicit cast (coercion) don't work for subquery's
results of unkown type, but works for constants is in the comment
cited above.

For "select ''::text = ' '", the internal intermediate
representation of the expression looks something like this,

Equal(text_const(''), unknown_const(' '))

and the second parameter can be immediately converted into
text_const(' ') during expression transformation in parse phase.

On the other hand, the problematic query is represented as
follows,

Equal(text_const(a), unknown_const(b))
for select ''::text as a, ' ' as b

But as described in the comment, PostgreSQL knows what to do but
it couldn't be implemented at the time of.. 7.3? But it seems to
be doable now.

By the way, the following query is similar to the problematic one
but doesn't fail.

SELECT a = b FROM (SELECT ''::text, ' ' UNION ALL SELECT '':text,
' ') AS x(a, b);

This is because parsing of UNION immediately converts constants
of unknown type in the UNION's both arms to text so the top level
select won't be bothered by this problem. But the problematic
query doesn't have appropriate timing to do that until the
function I patched.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center