Re: Number of attributes in HeapTupleHeader - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject Re: Number of attributes in HeapTupleHeader
Date
Msg-id 3CD72923.629CC3D9@tpf.co.jp
Whole thread Raw
In response to Number of attributes in HeapTupleHeader  (Manfred Koizar <mkoi-pg@aon.at>)
List pgsql-hackers
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 Inouehttp://w2422.nsk.ne.jp/~inoue/


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: pgsql_data/base mapping
Next
From: "Rod Taylor"
Date:
Subject: Re: Number of attributes in HeapTupleHeader