Re: alter table drop column status - Mailing list pgsql-hackers

From Jean-Michel POURE
Subject Re: alter table drop column status
Date
Msg-id 200202140916.g1E9GXL09930@www1.translationforge
Whole thread Raw
In response to Re: alter table drop column status  (Kovacs Zoltan <kovacsz@pc10.radnoti-szeged.sulinet.hu>)
Responses Re: alter table drop column status  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
List pgsql-hackers
Le Mercredi 13 Février 2002 18:23, Kovacs Zoltan a écrit :
> I wanted to know if I should wait for the solution of the full ALTER TABLE
> implementation or not. I'm afraid I shouldn't wait, should I? ;-)

What we could do using pgAdmin2 is :
("table_from" is the table to be modified, "table_to" is the resulting table)

1) Mark objects for deletion
* mark columns in "table_from" for deletion,
* mark primary keys in "table_from" for deletion,
* mark foreign keys in "table_from" for deletion,

2) Copy schema and data
* copy "table_to" structure out of "table_from" keeing only marked objects,
* copy data from "table_from" to "table_to",

3) Add rules and triggers, rename
* add "table_from" triggers to "table_to",
* add "table_from" rules to "table_to",
* drop table "table_from",
* rename "table_to".

The same script should also work for inherited tables.

This could be a hack until equivalent features are added natively to 
PostgreSQL. Do you think it is relevant to add this feature to pgAdmin2? Does 
Hiroshi script provide the same kind of features?

What is your opinion my dear friends? We wait for your advice.

Cheers,
jean-Michel POURE


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: NAMEDATALEN Changes
Next
From: Greg Copeland
Date:
Subject: Re: NAMEDATALEN Changes