| From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Kovacs Zoltan" <kovacsz(at)pc10(dot)radnoti-szeged(dot)sulinet(dot)hu> |
| Cc: | <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: alter table drop column status |
| Date: | 2002-02-13 05:14:59 |
| Message-ID: | GNELIHDDFBOCMGBFGEFOMEFPCBAA.chriskl@familyhealth.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> No there was an unapplied hack which uses logical/physical
> attribute numbers. I have synchronized it with cvs for a
> year or so but stop it now. Though it had some flaws It
> solved the following TODOs.
>
> * Add ALTER TABLE DROP COLUMN feature
> * ALTER TABLE ADD COLUMN to inherited table put column in wrong place
> * Prevent column dropping if column is used by foreign key
This seems fantastic - why can't this be committed? Surely if it's
committed then the flaws will fairly quickly be ironed out? Even if it has
flaws, then if we say 'this function is not yet stable' at least people can
start testing it and reporting the problems?
> I gave up to apply the hack mainly because it may introduce
> the maintenance headache.
Is it a maintenance headache just for you to keep it up to date, or how
would it be a maintenance headache if it were committed?
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gordon Runkle | 2002-02-13 05:22:34 | Odd statistics behaviour in 7.2 |
| Previous Message | Sean Alphonse | 2002-02-13 05:03:03 | Connection Pooling |