From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Postgres-Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Failure to coerce unknown type to specific type |
Date: | 2015-05-01 05:50:50 |
Message-ID: | 1430459450.2499.17.camel@jeff-desktop |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2015-05-01 10:51:50 | Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
Previous Message | Heikki Linnakangas | 2015-05-01 04:48:08 | Re: BUG #12845: The GB18030 encoding doesn't support Unicode characters over 0xFFFF |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-05-01 05:56:15 | Re: feature freeze and beta schedule |
Previous Message | Pavel Stehule | 2015-05-01 05:48:38 | Re: Faster setup_param_list() in plpgsql |