Re: Failure to coerce unknown type to specific type - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Failure to coerce unknown type to specific type
Date
Msg-id 35651.1430347071@sss.pgh.pa.us
Whole thread Raw
In response to Re: Failure to coerce unknown type to specific type  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Failure to coerce unknown type to specific type
Re: Failure to coerce unknown type to specific type
Re: Failure to coerce unknown type to specific type
List pgsql-bugs
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Apr 8, 2015 at 9:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Jeff Davis <pgsql@j-davis.com> writes:
>>> Original report and patch by Karl Schnaitter.
>>> create table a(u) as select '1';

>> We should, in fact, fail that to begin with.  Unknown-type columns are
>> a spectactularly horrid idea.

> I agree.  So why don't we throw an error when someone tries to create one?

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.

I have some recollection that we'd also put it off pending resolution of
debates about how to handle unknown-type literals in UNIONs and similar
contexts.  But poking at such examples right now, the behavior seems
generally reasonable: it seems like we resolve "unknown" as text when
forced to make a decision, but otherwise put it off as long as possible.
So that consideration may be obsolete.

An alternative design that is also worthy of consideration is to force
the created view or table column to be type text rather than unknown.
But that would be more complex to implement, and it's not obviously
superior to saying "hey bud, you need to be more specific as to what
column type you intend here".

            regards, tom lane

pgsql-bugs by date:

Previous
From: "bzb.dev001@gmail.com"
Date:
Subject: Re: BUG #13188: .pgpass does not work
Next
From: Amit Kapila
Date:
Subject: Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)