Re: [HACKERS] Re: ALTER TABLE DROP COLUMN

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Don Baccus <dhogaza(at)pacifier(dot)com>
Cc: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
Date: 2000-02-28 09:45:52
Message-ID: 38BA43D0.559054E4@tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Don Baccus wrote:
>
> At 12:21 PM 2/28/00 +0900, Hiroshi Inoue wrote:
>
> >My idea is essentially an invisible column implementation.
> >DROP COLUMN would change the target pg_attribute tuple
> >as follows..
>
> I don't see such a solution as being mutually exclusive with
> the other one on the table.

Very true, and we will need the hidden columns feature for a clean
implementation of inheritance anyway.

> Remember ... Oracle provides both. I suspect that they did so
> because they were under customer pressure to provide a "real"
> column drop and a "fast" (and non-2x tablesize!) solution. So
> they did both. Also keep in mind that being able to drop a
> column in Oracle is a year 1999 feature ... and both are provided.
> More evidence of pressure from two points of view.
>
> Of course, PG suffers because the "real" column drop is a 2x
> space solution, so the "invisibility" approach may more frequently
> be desired.

"update t set id=id+1" is also a 2x space, likely even more if
referential inheritance is used (and checked at the end of transaction)

And my main use of DROP COLUMN will probably be during development,
usually meaning small table sizes.

------------
Hannu

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Broytmann 2000-02-28 10:03:10 Locale support broken in latest snapshots
Previous Message Joaquin Eduardo Monje 2000-02-28 09:41:08 ask sybase - postgres