On Fri, May 1, 2015 at 1:50 AM, Jeff Davis <pgsql@j-davis.com> wrote:
> On Wed, 2015-04-29 at 15:37 -0700, Tom Lane wrote:
>> We should IMO, but there's been push-back about backwards compatibility
>> when this has been proposed in the past. But I'd rather break backwards
>> compatibility to the extent of saying "you can't do that" than to try to
>> make unknown a full-fledged type, which is what this patch wants to do.
>
> My intention was to make can_coerce_type and coerce_type consistent --
> right now, coerce_type can fail after can_coerce_type returns true.
>
> (I also wanted to improve the composability of subqueries, but I got
> enough resistance that I'm setting that argument aside.)
>
> It really has nothing to do with creating real tables with real columns
> of type unknown.
>
> => select u=t from (select 'x' as u, 'y'::text as t) s;
> ERROR: failed to find conversion function from unknown to text
>
> That's an elog (not an ereport, just plain elog) for what is a
> high-level query compilation error of a fairly sane-looking query, which
> seems wrong.
>
> The code comment above the error says that the caller blew it, but as
> far as I can tell there's nothing the caller can do about it. That seems
> wrong, too.
I agree. I'm not sure what the right fix is, but that query should
probably work, and if it must fail, it certainly shouldn't elog().
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company