Re: alter table drop column status
От | Hiroshi Inoue |
---|---|
Тема | Re: alter table drop column status |
Дата | |
Msg-id | EKEJJICOHDIEMGPNIFIJMEEHGMAA.Inoue@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: alter table drop column status (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: alter table drop column status
|
Список | pgsql-hackers |
> -----Original Message----- > From: Tom Lane > > Kovacs Zoltan <kovacsz@pc10.radnoti-szeged.sulinet.hu> writes: > > Browsing the archives, I found the latest comment about dropping columns > > about summer 2000 closing with Hiroshi's unapplied (?) hack. What is the > > current status of the implementation? > > It was applied, 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 I gave up to apply the hack mainly because it may introduce the maintenance headache. > and it's in there with #ifdef _DROP_COLUMN_HACK__, > but I believe Hiroshi has given up on that approach as unworkable. > > The #ifdef'd code is still there (in most places anyway) because no > one has bothered to rip it out. But I doubt it would work very well > if enabled --- the code mods in the last year or so have not taken > any notice of _DROP_COLUMN_HACK__. The code doesn't work since long. I would remove it after 7.3 tree is branched. regards, Hiroshi Inoue
В списке pgsql-hackers по дате отправления: