Re: Happy column adding (was RE: [HACKERS] Happy column dropping)

Don Baccus  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