From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
Cc: | Hannu Krosing <hannu(at)tm(dot)ee>, Michael Richards <miker(at)interchange(dot)ca>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Tuple data |
Date: | 2000-12-18 01:05:40 |
Message-ID: | 8405.977101540@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)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. To make it usable for inherited tables requires truly
horrendous kluges (as you well know). 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.
I have a similar opinion about DROP COLUMN ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Richards | 2000-12-18 01:37:03 | Re: Tuple data |
Previous Message | Hiroshi Inoue | 2000-12-18 00:41:39 | Re: TOAST-table vacuuming (was Re: Idea for reducing planning time) |