Re: DROP COLUMN

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Rod Taylor" <rbt(at)zort(dot)ca>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: DROP COLUMN
Date: 2002-07-16 16:19:42
Message-ID: EKEJJICOHDIEMGPNIFIJMEMHIGAA.Inoue@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: Bruce Momjian
>
> Christopher Kings-Lynne wrote:
> > > Uh, then what? The only idea I had was to set a static boolean
> > > variable in
> > > syscache.c that controls whether droppped columns are
> returned, and have
> > > a enable/disable functions that can turn it on/off. The only
> problem is
> > > that an elog inside a syscache lookup would leave that value set.
> > >
> > > My only other idea is to make a syscache that is like ATTNAME except
> > > that it doesn't return a dropped column. I could probably
> code that up
> > > if you wish.
> >
> > That'd be cool.
> >
> > I guess the thing is that either way, I will need to manually
> change every
> > single instance where a dropped column should be avoided. So, really
> > there's not much difference between me changing the SysCache
> search to use
> > ATTNAMEUNDROPPED or whatever, or just checking the attisdropped
> field of the
> > tuple in the same way that you must always check that attnum > 0.
> >
> > In fact, looking at it logically...if all the commands currently are
> > required to check that they're not modifiying a system column,
> then why not
> > add the requirement that they must also not modify dropped
> columns? I can
> > do a careful doc search and try to make sure I've touched everything...
>
> Makes sense. Of course, we could make a syscache that didn't return
> system columns either.
>
> Actually, the original argument for negative attno's for dropped columns
> was exactly for this case, that the system column check would catch
> dropped columns too,

> but it causes other problems that are harder to fix
> so we _dropped_ the idea.

What does this mean ?
BTW would we do nothing for clients after all ?

regards,
Hiroshi Inoue

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-07-16 16:23:01 OID suppression issues
Previous Message Lamar Owen 2002-07-16 16:10:23 Re: [SQL] line datatype