Re: Failure to coerce unknown type to specific type

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Failure to coerce unknown type to specific type
Дата
Msg-id 1430459450.2499.17.camel@jeff-desktop
обсуждение исходный текст
Ответ на Re: Failure to coerce unknown type to specific type  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Failure to coerce unknown type to specific type  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-bugs
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.

Regards,
    Jeff Davis

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: BUG #12845: The GB18030 encoding doesn't support Unicode characters over 0xFFFF
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)