> The nice thing about this implementation approach is that most of the
> backend need not be aware of deleted columns. There are a few places in
> the parser (probably few enough to count on one hand) that will have to
> explicitly check for and reject references to dropped columns, and
> you're
> This part should fall out of Rod Taylor's pg_depend stuff pretty easily.
> We still need to debate about the behavior, though. If for example there
> is a unique index on column B, do you need "DROP B CASCADE" to get rid
> of it, or is "DROP B RESTRICT" good enough? Does your answer change if
Hannu Krosing <[EMAIL PROTECTED]> writes:
>> The DROP COLUMN command does nothing but set the attisdropped of a column to
>> true,
> This will probably require a full lock on system tables to avoid nasty
> border conditions when updating caches.
AFAICS it's no different from any other ALTER TAB
On Mon, 2002-07-01 at 09:47, Christopher Kings-Lynne wrote:
> Hi All,
>
> I've been thinking about this DROP COLUMN business (sorry to start another
> spammy, flamey thread!). I'm taking ideas from lots of sources here.
>
> How does this sound for a process?
>
> 1.
> A new column is added to p
> 2.
> The column expansion (*) code and the code that checks for valid column
> references everywhere in the codebase is changed to also check the
> attisdropped field. Does someone have a comprehensive list of
> places to be
> changed?
Actually - did Hiroshi(?)'s original HACK have this code -
Hi All,
I've been thinking about this DROP COLUMN business (sorry to start another
spammy, flamey thread!). I'm taking ideas from lots of sources here.
How does this sound for a process?
1.
A new column is added to pg_attribute called 'attisdropped'. It, of course,
defaults to false.
2.
The
