Re: [BUGS] Bug #513: union all changes char(3) column definition
От | Bruce Momjian |
---|---|
Тема | Re: [BUGS] Bug #513: union all changes char(3) column definition |
Дата | |
Msg-id | 200111220353.fAM3rRg12994@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] Bug #513: union all changes char(3) column definition (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] Bug #513: union all changes char(3) column definition
|
Список | pgsql-hackers |
> regression=# create table baz as select f1 || 'z' as f1 from foo; > SELECT > regression=# \d baz > Table "baz" > Column | Type | Modifiers > --------+--------+----------- > f1 | bpchar | > > The argument here is about how much intelligence it's reasonable to > expect the system to have. It's very clearly not feasible to derive > a length limit automagically in every case. How hard should we try? I don't think we can try in this case, especially because our functions are all burried down in adt/. However, I don't think creating a bpchar with no length is a proper solution. Should we just punt to text in these cases? Seems cleaner, perhaps even throw an elog(NOTICE) mentioning the promotion to text. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: