Re: Happy column adding (was RE: [HACKERS] Happy column dropping)
От | Bruce Momjian |
---|---|
Тема | Re: Happy column adding (was RE: [HACKERS] Happy column dropping) |
Дата | |
Msg-id | 200001252008.PAA20667@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Happy column adding (was RE: [HACKERS] Happy column dropping) (Don Baccus <dhogaza@pacifier.com>) |
Список | pgsql-hackers |
> At 11:55 AM 1/25/00 +0100, Peter Eisentraut wrote: > >On Tue, 25 Jan 2000, Hiroshi Inoue wrote: > > > >> Even default is not allowed in ADD COLUMN now. > >> There may be other reasons why they aren't allowed. > > > >It's not a matter of *allowed*, it's a parsing deficiency. The fact that > >there was a default declared gets silently ignored. If y'all allow ;) I > >would like to fix that (have already started a bit) by perusing the code > >in parse_func.c:transformCreateStmt and do the same for the alter table > >add column part. Maybe and add/drop constraint will come out in the end as > >well. > > However, heap_getattr still won't see the default since it simply > checks to see of the attribute number falls off the end of the > tuple and then returns null. > > There's no provision for then pulling out the default value and > returning it instead. > > I think this is why Tom was implying that add column should really > alter the table? > > A fully-featured "add column" feature would be very nice, indeed. Oh, so that is why ALTER TABLE can't have a NOT NULLL default. Makes total sense. -- Bruce Momjian | http://www.op.net/~candle 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 по дате отправления: