From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Peter Eisentraut" <peter_e(at)gmx(dot)net> |
Cc: | <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | RE: [HACKERS] Well, then you keep your darn columns |
Date: | 2000-01-24 17:12:25 |
Message-ID: | NDBBIJLOILGIKBGDINDFAEFDCCAA.Inoue@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)org]On Behalf Of Peter Eisentraut
>
> Let me thank all of those that spoke up in my support and let me tell of
> those that were unhappy that I _will_ be here tomorrow as well. To
> summarize the points and add a few of my own:
>
> 1) This is a TODO item.
>
> 2) I have reviewed several mutterings about how to implement this in the
> archives and followed the consensus that you need to copy the table over
> somehow. It's not like I made this up.
>
> 2a) Does anyone have a better idea? (Btw., I'm not too excited about
> by-passing the storage manager and writing around in the table file on
> disk. If vacuum does that, that doesn't mean it's the right thing to do.)
>
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.
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 | Michael Robinson | 2000-01-24 17:12:28 | Re: [HACKERS] fatal copy in/out error (6.5.3) |
Previous Message | Bruce Momjian | 2000-01-24 17:03:06 | Re: [HACKERS] column aliases |