RE: Happy column adding (was RE: [HACKERS] Happy column dropping)

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема RE: Happy column adding (was RE: [HACKERS] Happy column dropping)
Дата
Msg-id NDBBIJLOILGIKBGDINDFIEFOCCAA.Inoue@tpf.co.jp
обсуждение исходный текст
Ответ на Happy column adding (was RE: [HACKERS] Happy column dropping)  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
Список pgsql-hackers
> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> > But, considering the fact that DEFAULT can be something reaaly 
> > complex, like
> > function that does a lot of things, it may be better to have the 
> > constraints
> > checked at the end of transaction, like
> > 
> > BEGIN;
> > ALTER TABLE T1 ADD COLUMN C1 TEXT NOT NULL;
> 
> Isn't 'iNITIALLY DEFERRED' needed ?
> ALTER TABLE T1 ADD COLUMN C1 TEXT NOT NULL INITIALLY DEFERRED;
> 
> > UPDATE T1 SET C1='MYDEFAULTVALUE';
> > COMMIT;
> >
> 
> It seems more reasonable than standard.
> But is it worth breaking SQL standard ?
>

Seems I was wrong. It's not so good.
Current spec to reject NOT NULL/DEFAULT for new column
isn't so bad and ADD CONSTRAINT feature is much more
important. How about the following ?

BEGIN;
ALTER TABLE T1 ADD COLUMN C1 TEXT;
UPDATE T1 SET C1='MYDEFAULTVALUE';
ALTER TABLE T1 ADD CONSTRAINT CHECK C1 NOT NULL;
COMMIT;

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Zeugswetter Andreas SB
Дата:
Сообщение: AW: AW: AW: [HACKERS] Some notes on optimizer cost estimates
Следующее
От: Jose Soares
Дата:
Сообщение: Re: Happy column adding (was RE: [HACKERS] Happy column dropping)