Don Baccus <dhogaza@pacifier.com> writes:
>> 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.
> Yes...I see what you're driving at. Very interesting idea. The stored
> rules and constraints would in this case would still refer to the remaining
> columns after a drop, right?
Right. You'd still need to scan through all the rules/constraints to
look for references to a column-to-be-dropped (and then either drop that
rule/constraint or kick out an error, as appropriate). But you wouldn't
have to *change* any surviving rules/constraints, because they'd still
be referring to the same permanent IDs of the remaining columns.
Also, inherited ADD COLUMN would become far easier, because it wouldn't
change the rules/constraints of child tables at all --- even though the
new column would change the logical numbering of child-table columns,
it wouldn't change their permanent IDs and thus we wouldn't have to
update rules/constraints.
If we were willing to hardwire the assumption that DROP COLUMN never
physically drops a column, but only hides it and adjusts logical column
numbers, then the physical column numbers could serve as permanent IDs;
so we'd only need two numbers not three. This might be good, or not.
regards, tom lane
