Re: [HACKERS] Well, then you keep your darn columns

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

In response to

Browse pgsql-hackers by date

  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