Tom Lane wrote: > Hiroshi Inoue <[EMAIL PROTECTED]> writes: > > I used the following macro in my trial implementation. > > #define COLUMN_IS_DROPPED(attribute) ((attribute)->attnum <= > > DROP_COLUMN_OFFSET) > > The places where the macro was put are exactly the places > > where attisdropped must be checked. > > Actually, your trial required column dropped-ness to be checked in > many more places than the proposed approach does. Since you renumbered > the dropped column, nominal column numbers didn't correspond to physical > order of values in tuples anymore; that meant checking for dropped > columns in many low-level tuple manipulations. > > >> Is this correct? I certainly prefer attno renumbering to isdropped > >> because it allows us to get DROP COLUMN without any client changes, > > > Unfortunately many apps rely on the fact that the attnos are > > consecutive starting from 1. It was the main reason why Tom > > rejected my trial. Nothing has changed about it. > > I'm still not thrilled about it ... but I don't see a reasonable way > around it, either. I don't see any good way to do DROP COLUMN > without breaking applications that make such assumptions. Unless > you have one, we may as well go for the approach that adds the least > complication to the backend.
It may turn out to be a choice of client-cleanliness vs. backend cleanliness. Seems Hiroshi already wins for client cleanliness. We just need to know how many extra places need to be checked in the backend. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
