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