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  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [BUGS] Bug #513: union all changes char(3) column definition  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Diff/Patch integration -> SQL cvs clone
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [BUGS] Bug #513: union all changes char(3) column definition