I think the real trick is keeping track of the difference between:
begin;
ALTER TABLE tab ADD COLUMN col1 int4 DEFAULT 4;
commit;
and
begin;
ALTER TABLE tab ADD COLUMN col1;
ALTER TABLE tab ALTER COLUMN col1 SET DEFAULT 4;
commit;
The first should populate the column with the value of '4', the second
should populate the column with NULL and have new entries with default
of 4.
Not to mention
begin;
ALTER TABLE tab ADD COLUMN col1 DEFAULT 5;
ALTER TABLE tab ALTER COLUMN col1 SET DEFAULT 4;
commit;
New tuples with default value of 4, but the column creation should
have 5.
--
Rod
----- Original Message -----
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Neil Conway" <nconway@klamath.dyndns.org>
Cc: <mkoi-pg@aon.at>; <pgsql-hackers@postgresql.org>
Sent: Monday, May 06, 2002 9:08 PM
Subject: Re: [HACKERS] Number of attributes in HeapTupleHeader
> Neil Conway wrote:
> >
> > On Mon, 6 May 2002 08:44:27 +0900
> > "Hiroshi Inoue" <Inoue@tpf.co.jp> wrote:
> > > > -----Original Message-----
> > > > From: Manfred Koizar
> > > >
> > > > If there is interest in reducing on-disk tuple header size and
I have
> > > > not missed any strong arguments against dropping t_natts, I'll
> > > > investigate further. Comments?
> > >
> > > If a dbms is proper, it prepares a mechanism from the first
> > > to handle ADD COLUMN without touching the tuples. If the
> > > machanism is lost(I believe so) by removing t_natts, I would
> > > say good bye to PostgreSQL.
> >
> > IMHO, the current ADD COLUMN mechanism is a hack. Besides
requiring
> > redundant on-disk data (t_natts), it isn't SQL compliant (because
> > default values or NOT NULL can't be specified), and depends on
> > a low-level kludge (that the storage system will return NULL for
> > any attnums > the # of the attributes stored in the tuple).
>
> I think it's neither a hack nor a kludge.
> The value of data which are non-existent at the appearance
> is basically unknown. So there could be an implementation
> of ALTER TABLE ADD COLUMN .. DEFAULT which doesn't touch
> existent tuples at all as Oracle does.
> Though I don't object to touch tuples to implement ADD COLUMN
> .. DEFAULT, please don't change the existent stuff together.
>
> regards,
> Hiroshi Inoue
> http://w2422.nsk.ne.jp/~inoue/
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>