Tom Lane wrote:
>
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> >> Tom Lane wrote:
> >>>>> ALTER ADD COLUMN doesn't touch any tuples, and you're right that it's
> >>>> critically dependent on heap_getattr returning NULL when an attribute
> >>>> beyond the number of attributes actually present in a tuple is accessed.
> >>>> That's a fragile and unclean implementation IMHO --- see past traffic
> >>>> on this list.
>
> > I don't remember the traffic either.
> > IIRC,I objected to Tom at this point in pgsql-bugs recently.
>
> That was the traffic I was recalling ;-)
>
> > I think it's very important for dbms that ALTER ADD COLUMN
> > touches tuples as less as possible.
>
> I disagree. The existing ADD COLUMN implementation only works for
> appending columns at the end of tuples; it can't handle inserting
> a column.
Column order isn't essential in rdbms.
Isn't it well known that it's not preferable to use
'select *','insert' without column list etc.. in production
applications ?
> To make it usable for inherited tables requires truly
> horrendous kluges (as you well know).
Logical/physical attribute numbers solves it naturally.
> IMHO we'd be far better off
> to rewrite ADD COLUMN so that it does go through and change all the
> tuples, and then we could get rid of the hackery that tries --- not
> very successfully --- to deal with inconsistent column orders between
> parent and child tables.
>
We couldn't live without ALTER ADD COLUMN and it's
very critical for me to be able to ADD COLUMN even
when the target table is at full work.
It has been one of my criteria how cool the dbms is.
Fortunately PostgreSQL has been cool but ....
Regards.
Hiroshi Inoue