Re: BETWEEN Node & DROP COLUMN

Christopher Kings-Lynne wrote:
> Hi All,
>
> I have given up working on the BETWEEN node.  It got to the stage where I
> realised I was really out of my depth!  Rod Taylor has indicated an interest
> in the problem and I have sent him my latest patch, so hopefully he'll be
> able to crack it.
>
> So instead, I've taken up with the DROP COLUMN crusade.  It seems that the
> following are the jobs that need to be done:

Great crusade!

> * Add attisdropped to pg_attribute
>   - Looking for takers for this one, otherwise I'll look into it.

I can do this for you.  Just let me know when.

> * Fill out AlterTableDropColumn
>   - I've done this, with the assumption that attisdropped exists.  It sets
> attisdropped to true, drops the column default and renames the column.
> (Plus does all other normal ALTER TABLE checks)
> * Modify parser and other places to ignore dropped columns
>   - This is also up for grabs.

As I remember, Hiroshi's drop column changed the attribute number to a
special negative value, which required lots of changes to track.
Keeping the same number and just marking the column as dropped is a big
win.  This does push the coding out the client though.

> * Modify psql and pg_dump to handle dropped columns
>   - I've done this.
> 
> Once the above is done, we have a working drop column implementation.
> 
> * Modify all other interfaces, JDBC, etc. to handle dropped cols.
>   - I think this can be suggested to the relevant developers once the above
> is committed!
> 
> * Modify VACUUM to add a RECLAIM option to reduce on disk table size.
>   - This is out of my league, so it's up for grabs

Will UPDATE on a row set the deleted column to NULL?  If so, the
disk space used by the column would go away over time.  In fact, a
simple:UPDATE tab SET col = col;VACUUM;

would remove the data stored in the deleted column;  no change to VACUUM
needed.

> I have approached a couple of people off-list to see if they're interested
> in helping, so please post to the list if you intend to work on something.
> 
> It has also occurred to me that once drop column exists, users will be able
> to change the type of their columns manually (ie. create a new col, update
> all values, drop the old col).  So, there is no reason why this new
> attisdropped field shouldn't allow us to implement a full ALTER TABLE/SET
> TYPE sort of feature - cool huh?

Yep.
--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026