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