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
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 |