Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 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.
I'm not convinced about it either --- but at this point the discussion
is just a gedanken-experiment to see what problems would be solved
or created if we did something like this. It could be that having
invisible columns (or more likely, separate logical and physical
column numbers) would solve enough nagging problems with ADD COLUMN
and DROP COLUMN and inherited tables that it'd be worth doing.
Or not. But let's not shut off the discussion before we see where
it leads.
Following on to my comment about logical column numbers, physical
column positions, and permanent column IDs being conceptually
distinct: one thing that needs careful consideration is just how
we identify inherited columns in child tables as being the "same
column" as the original column in the parent. Right now, because
ADD COLUMN doesn't guarantee to assign the same column number in
each child, the parser/planner handles this by looking for the
same column name in each child table, which it does on-the-fly
while setting up a "SELECT table*" operation. That's pretty much
of a kluge in my opinion. My guess is that we ought to use either
logical column number or permanent ID as the key that tells us which
child column is the inherited one. To use permanent ID, we'd have
to ensure that permanent IDs are inheritable, which would complicate
assignment of permanent IDs considerably --- they'd probably have to
become OIDs, but not the same OIDs as are assigned to the pg_attribute
rows themselves. Logical column number might work OK for this purpose
though. It seems a little shaky to me intuitively, but I can't actually
think of a reason that it wouldn't work.
regards, tom lane
