Re: BETWEEN Node & DROP COLUMN

From: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
To: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BETWEEN Node & DROP COLUMN
Date: 2002-07-05 06:28:04
Message-ID: GNELIHDDFBOCMGBFGEFOCEPMCCAA.chriskl@familyhealth.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > pg_attribute is very possibly the most ticklish system catalog
> > to add a column to. I'd suggest looking through every single use of
> > some other pg_attribute column, perhaps attstattarget or attnotnull,
> > to make sure you're initializing attisdropped everywhere it should be.

Done.

Wow - I've almost finished it now, actually! It's at the stage where
everything works as expected, all the initdb attributes are properly marked
not dropped, the drop column command works fine and psql works fine. All
regression tests also pass. '*' expansion works properly.

I have a lot of testing to go, however. I will make up regression tests as
well.

Some questions:

1. I'm going to prevent people from dropping the last column in their table.
I think this is the safest option. How do I check if there's any other non
dropped columns in a table? Reference code anywhere?

2. What should I do about inheritance? I'm going to implement it, but are
there issues? It will basically drop the column with the same name in all
child tables. Is that correct behaviour?

3. I am going to initially implement the patch to ignore the behaviour and
do no dependency checking. I will assume that Rod's patch will handle that
without much trouble.

Thanks,

Chris

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2002-07-05 06:28:47 Re: CLUSTER not lose indexes
Previous Message Bruce Momjian 2002-07-05 06:01:00 Re: Issues Outstanding for Point In Time Recovery (PITR)