Re: [HACKERS] Well, then you keep your darn columns - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: [HACKERS] Well, then you keep your darn columns
Date
Msg-id 388CCF9F.809E93AC@tm.ee
Whole thread Raw
In response to Re: [HACKERS] Well, then you keep your darn columns  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [HACKERS] Well, then you keep your darn columns
List pgsql-hackers
Bruce Momjian wrote:
> 
> > > The only drawback of this scheme is that the space occupied by the
> > > deleted column wouldn't go away immediately (in any given tuple,
> > > it'd be reclaimed on the next UPDATE of the tuple).  On the other hand,
> > > you could construe that as a feature --- you don't have to wait around
> > > for a DROP COLUMN to finish.  Anyone who did want to reclaim space
> > > immediately could do
> > >     UPDATE table SET someothercolumn = someothercolumn;
> > > followed by a VACUUM.  But I bet a lot of people would be just as
> > > happy to let it happen in background.
> >
> > Hey Bruce ... Look here ^^^^ :)
> >
> > Oh, there is a second drawback to it though ...
> >
> > DROP COLUMN name
> > ADD COLUMN name <of a different type>

or the same type, it will be added at the end anyway.

part of making it invisible should be making its _name_ invisible in pg_*

one way would be to rename it to '\n'+str(next_available_oid) or sone other 
invalid column name.

> >
> > Then what? :(
> 
> Double-yikes.  There goes that idea, or does it?  Attributes are
> numbered.  How does a missing attribute get handled for new rows?

The proposition was to set it always to NULL (takes no additional storage
if there are other null columns, (fieldcnt+31)/8 bytes else.

BTW, the current handling of nulls in storage is a bit weird - the bitvector
for 
null/not null starts at position 31, but if there is a bitmap space is
allocated 
in 4-byte chunks starting at position 32  (at least on linux/x86)

> My guess is that we have to keep this thing around forever.

Or until dump/reload, the renumbering will be automatic there.

> Can you
> imagine having all those user apps tha query pg_attribute supress that
> column.  Sound like too much work to me.

To me it sounds like a thing that _must_ be done at major number change, 
so 7.0 is a good place.

OTOH, we could provide SQL92 ways for getting the info that current user 
apps get by querying pg_attribute.

IIRC it requires a bunch of views on system tables, some of which could be 
lifted straight from psql's \d* commands.

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


pgsql-hackers by date:

Previous
From: "Oliver Elphick"
Date:
Subject: Inheritance, referential integrity and other constraints
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Well, then you keep your darn columns