Re: Happy column adding (was RE: [HACKERS] Happy column dropping)
| От | Tom Lane |
|---|---|
| Тема | Re: Happy column adding (was RE: [HACKERS] Happy column dropping) |
| Дата | |
| Msg-id | 14033.948820995@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | RE: Happy column adding (was RE: [HACKERS] Happy column dropping) ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
| Ответы |
Re: Happy column adding (was RE: [HACKERS] Happy column dropping)
Re: Happy column adding (was RE: [HACKERS] Happy column dropping) Re: Happy column adding |
| Список | pgsql-hackers |
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
>>>> Even default is not allowed in ADD COLUMN now.
>>
>> It's not a matter of *allowed*, it's a parsing deficiency. The fact that
>> there was a default declared gets silently ignored.
> IIRC,there were some reason that default for new column had been rejected.
Well, yeah: wouldn't you expect that "ADD COLUMN x DEFAULT 42" would
cause every row currently existing in the table to acquire x = 42,
rather than x = NULL? In fact that would *have* to happen to allow
constraints to be added; consider ADD COLUMN x DEFAULT 42 NOT NULL.
The only way to make that happen is for ADD COLUMN to switch over to
an implementation that rewrites all the tuples. Which I think is the
right way to go ... but per this discussion, it's not a trivial fix.
regards, tom lane
В списке pgsql-hackers по дате отправления: