From: | Don Baccus <dhogaza(at)pacifier(dot)com> |
---|---|
To: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "PostgreSQL Development" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | RE: [HACKERS] Re: ALTER TABLE DROP COLUMN |
Date: | 2000-02-28 05:26:30 |
Message-ID: | 3.0.1.32.20000227212630.00fbfb20@mail.pacifier.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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.
Still... as time goes on and PG gets adopted by more and more
serious, large-scale users (which we all are working towards,
right?) I suspect that each camp will want to be served.
- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From | Date | Subject | |
---|---|---|---|
Next Message | Don Baccus | 2000-02-28 05:30:06 | RE: [HACKERS] Re: ALTER TABLE DROP COLUMN |
Previous Message | Hiroshi Inoue | 2000-02-28 04:25:06 | RE: [HACKERS] Re: ALTER TABLE DROP COLUMN |