Re: Happy column adding (was RE: [HACKERS] Happy column dropping)
Bruce Momjian <pgman@candle.pha.pa.us>
From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Don Baccus <dhogaza@pacifier.com>
Cc: Peter Eisentraut <peter_e@gmx.net>, Hiroshi Inoue <Inoue@tpf.co.jp>, PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Date: 2000-01-25T20:08:15Z
Lists: 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, Pennsylvania 19026