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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026