From: | Chris Bitmead <chris(at)bitmead(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Well, then you keep your darn columns |
Date: | 2000-01-24 23:20:49 |
Message-ID: | 388CDE51.E5240641@bitmead.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hiroshi Inoue wrote:
> I propose another implementation here. I don't think this is so
> important a feature. I'm only afraid of forced implementation
> especially using copy() and rename() for such a feature.
Hi all....
Can I just point out that the above is THE RIGHT THING(tm). I havn't
followed this thread from the beginning, but can I point out that
implementing drop column as a copy/rename is not good (better than
nothing I guess).
Take a cue from a database like VERSANT (http://www.versant.com) You
can change the database's schema while the database is running. Time
taken to delete a column is roughly 0.0 seconds no matter how large the
table. Going the whole hog, you keep the old schema available so that
when you retrieve an old tuple it can be updated the next time that
tuple is updated.
>
> My idea is as follows.
>
> 1)add a visibile/invisible flag to pg_attribute
> 2)DROP COLUMN marks the column as invisible
> 3)user interface ignores the columns which are marked invisible
> 4)heap_formtuple() etc treats the column as NULL internally
>
> Regards.
>
> Hiroshi Inoue
> Inoue(at)tpf(dot)co(dot)jp
>
> ************
From | Date | Subject | |
---|---|---|---|
Next Message | Patrick Welche | 2000-01-24 23:31:19 | Re: [HACKERS] Re: pg_dump possible fix, need testers. |
Previous Message | Don Baccus | 2000-01-24 23:17:44 | Re: [HACKERS] Well, then you keep your darn columns |