Re: Failure to coerce unknown type to specific type
От | Robert Haas |
---|---|
Тема | Re: Failure to coerce unknown type to specific type |
Дата | |
Msg-id | CA+TgmoaUNFTvUnmV3Fj+kK-TyjVN_S0zNSD_hMBYP8kMCo1d3g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Failure to coerce unknown type to specific type (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Failure to coerce unknown type to specific type
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: