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

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

In response to

Responses

Browse pgsql-hackers by date

  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