Bruce Momjian wrote:
>
> Seems we have 4 DROP COLUMN ideas:
>
> Method Advantage
> -----------------------------------------------------------------
> 1 invisible column marked by negative attnum fast
> 2 invisible column marked by is_dropped column fast
> 3 make copy of table without column col removed
> 4 make new tuples in existing table without column col removed
IIRC there was a fifth idea, a variation of 2 that would work better
with
inheritance -
5 all columns have is_real_column attribute that is true for all
coluns
present in that relation, so situations like
create table tab_a(a_i int);
create table tab_b(b_i int) inherits(tab_a);
alter table tab_a add column c_i int;
can be made to work.
It would also require clients to ignore all missing columns that backend
can
pass to them as nulls (which is usually quite cheap in bandwith usage)
in
case of "SELECT **" queries.
We could even rename attno to attid to make folks aware that it is not
be
assumed to be continuous.
> Folks, we had better choose one and get started.
>
> Number 1 Hiroshi has ifdef'ed out in the code. Items 1 and 2 have
> problems with backend code and 3rd party code not seeing the dropped
> columns, or having gaps in the attno numbering.
If we want to make ADD COLUMN to work with inheritance wihout having to
rewrite every single tuple in both parent and inherited tables, we will
have to accept the fact that there are caps in in attno numbering.
> Number 3 has problems
> with making it an atomic operation, and number 4 is described below.
Nr 4 has still problems with attno numbering _changing_ during drop
which
could either be better or worse for client software than having gaps -
in both cases client must be prepared to deal with runtime changes in
attribute definition.
--------------
Hannu
