> It occurs to me that in at least some of the places where attribute
> numbers are currently used, we ought to use *neither* logical nor
> physical column position, but rather a permanent unique ID --- the
> attribute tuple's OID would work, if it's assigned soon enough to be
> used for constraints given in CREATE TABLE. (Otherwise we could assign
> "column serial numbers" that count from 1 for each relation, but are
> never changed or recycled within the relation.)
>
> In particular, if parsetrees for stored rules and constraints worked
> that way, renumbering attributes that follow the added/dropped column
> would become a lot less painful.
I am going to object to any use of invisible columns just to get a nice
ALTER DROP COLUMN capability. It doesn't seeem with the added code
complexity. Our code is complex enough. Why add more to it just for
one feature.
-- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
