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

Don Baccus wrote:
> 
> Ahhh...yes.  I haven't looked at the inheritance code, yet, but I see
> what you're saying.  I think.  Do child-table columns follow parent-table
> columns by some chance (in today's absolute column number scheme)?
> 
> >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.
> 
> Yes.  But if I'm right about how child-table columns are numbered,
> wouldn't add column still cause a problem, i.e. you'd still have to
> change their physical column number?

If we allow deleted column as a basic feature of postgres,
it could be like that 

base:    COL1 | COL2 | COL3 
child:   COL1 | COL2 | COL3 | COL4

after add column 5 to base table

base:    COL1 | COL2 | COL3 | del4 | COL5 
child:   COL1 | COL2 | COL3 | COL4 | COL5

after add column 6 to child

base:    COL1 | COL2 | COL3 | del4 | COL5 
child:   COL1 | COL2 | COL3 | COL4 | COL5 | COL6

after drop column 2 from base table

base:    COL1 | del2 | COL3 | del4 | COL5 
child:   COL1 | del2 | COL3 | COL4 | COL5 | COL6

dropping column from child table that is not a deleted column in 
parent is not allowed.

The delN columns are always NULLed on reading tuple and are written as proper 
null columns (taking up space only in NULL bitmask)

multiple inheritance is tricky and _requires_ unique column ids maybe oids
from pg_attribute to be doable.

-----------------
Hannu