Re: [BUGS] Bug #513: union all changes char(3) column definition
От | Tom Lane |
---|---|
Тема | Re: [BUGS] Bug #513: union all changes char(3) column definition |
Дата | |
Msg-id | 27975.1006401064@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] Bug #513: union all changes char(3) column definition (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: [BUGS] Bug #513: union all changes char(3) column definition
Re: [BUGS] Bug #513: union all changes char(3) column definition |
Список | pgsql-hackers |
Bruce Momjian <pgman@candle.pha.pa.us> writes: > Added to TODO: > * CREATE TABLE AS can not determine column lengths from expressions > Seems it should be documented. Do we throw an error in these cases? No. What we do right now is to generate non-length-constrained column types for the created table. Your TODO item is too pessimistic: we *do* determine the column length in simple cases. For example: regression=# create table foo (f1 char(3)); CREATE regression=# create table bar as select * from foo; SELECT regression=# \d bar Table "bar"Column | Type | Modifiers --------+--------------+-----------f1 | character(3) | However, in more complex cases we don't know the column length: 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? regards, tom lane
В списке pgsql-hackers по дате отправления: