Re: DROP COLUMN

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

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

Chris

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-07-16 04:50:59 Re: DROP COLUMN
Previous Message Bruce Momjian 2002-07-16 04:38:49 Re: DROP COLUMN