On Mon, 28 Feb 2000, Hiroshi Inoue wrote:
> > -----Original Message-----
> > From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> > "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> > > Hmm,tuples of multiple version in a table ?
> > > This is neither clean nor easy for me.
> > I'm worried about it too. I think it could maybe be made to work,
> > but it seems fragile.
> > > I may be able to provide another implementation on trial and it
> > > may be easier than only objecting to your proposal.
> > If you have a better idea, let's hear it!
> I don't want a final implementation this time.
> What I want is to provide a quick hack for both others and me
> to judge whether this direction is good or not.
> My idea is essentially an invisible column implementation.
> DROP COLUMN would change the target pg_attribute tuple
> as follows..
> attnum -> an offset - attnum;
> atttypid -> 0
> We would be able to see where to change by tracking error/
> crashes caused by this change.
> I would also change attname to '*already dropped %d' for
> examle to avoid duplicate attname.
Okay, just curious here, but ... what you are proposing *sounds* to me
like half-way to what started this thread. (*Please* correct me if I'm
Essentially, in your proposal, when you drop a column, all subsequent
tuples inserted/updated would have ... that one column missing? So,
instead of doing a massive sweep through the table and removing that
column, only do it when an insert/update happens?
Basically, eliminate the requirement to re-write every tuples, only those
that have activity?
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2000-02-28 03:52:30|
|Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN|
|Previous:||From: Hiroshi Inoue||Date: 2000-02-28 03:21:36|
|Subject: RE: [HACKERS] Re: ALTER TABLE DROP COLUMN |