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

From Kovacs Zoltan
Subject Re: alter table drop column status
Date
Msg-id Pine.LNX.4.21.0202131812060.19769-100000@pc10.radnoti-szeged.sulinet.hu
Whole thread Raw
In response to Re: alter table drop column status  (Hiroshi Inoue <Inoue@tpf.co.jp>)
Responses Re: alter table drop column status  (Jean-Michel POURE <jm.poure@freesurf.fr>)
List pgsql-hackers
> to use immediately. I'm pretty suspicious if a developer
> could be careful about the choise when he is implementing
> an irrevant feature. (Un)fortunately the numbers have

Well, dropping a column doesn't seem to be a relevant feature. But
unfortunately our production system requires updates/upgrades "on the
fly", without stopping and dumping out/in the whole database. Currently
it's only about 16 megs of data but it's growing... I would be satisfied
with a working method for dropping and recreating only one table with a
short shutdown (~ a few minutes). The problem for me is that the foreign
key constraints of all referencing tables must be recreated and I want to
do this automagically. It would be enough for me if I could write a
script which does this reasonably fast.

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? ;-)

--                         Kov\'acs, Zolt\'an                        kovacsz@pc10.radnoti-szeged.sulinet.hu
          http://www.math.u-szeged.hu/~kovzol                        ftp://pc10.radnoti-szeged.sulinet.hu/home/kovacsz
 



pgsql-hackers by date:

Previous
From: "Gordon A. Runkle"
Date:
Subject: Re: Odd statistics behaviour in 7.2
Next
From: Neil Padgett
Date:
Subject: Re: Add free-behind capability for large sequential scans