Re: ALTER TABLE DROP COLUMN

I don't know if this is one of the 5, but my idea of a good
implementation is to do the fast invisible approach, and then update
individual tuples to the new format the next time they happen to be
UPDATEd.

Therefore, ALTER TABLE DROP COLUMN, followed by UPDATE foo SET bar=bar;
would cause the equiv of (4).

-- 
Chris Bitmead
mailto:chris@bitmead.com
Hannu Krosing wrote:
> 
> 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