Обсуждение: Re: ALTER TABLE DROP COLUMN

Поиск
Список
Период
Сортировка

Re: ALTER TABLE DROP COLUMN

От
Bruce Momjian
Дата:
> > -----Original Message-----
> > From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> > 
> > >> 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
> >
> 
> Hmm,I've received no pg-ML mails for more than 1 day.
> What's happened with pgsql ML ? 

Tom says there are tons of messages in the hub.org mail queue, but they
are not being delivered.

>  
> > Bruce and I talked about this by phone yesterday, and we realized that
> > none of these are very satisfactory.  #1 and #2 both have the flaw that
> > applications that examine pg_attribute will probably break: they will
> > see a sequence of attnum values with gaps in it.  And what should the
> > rel's relnatts field be set to?  #3 and #4 are better on that point,
> > but they leave us with the problem of renumbering references to columns
> > after the dropped one in constraints, rules, PL functions, etc.
> > 
> > Furthermore, there is a closely related problem that none of these
> > approaches give us much help on: recursive ALTER TABLE ADD COLUMN.
> > Right now, ADD puts the new column at the end of each table it's added
> > to, which often means that it gets a different column number in child
> > tables than in parent tables.  That leads to havoc for pg_dump.
> >
> 
> Inheritance is one of the reason why I didn't take #2. I don't understand 
> marking is_dropped is needed or not when pg_attribute is overhauled
> for inheritance.
> I myself have never wanted to use current inheritance functionality
> mainly because of this big flaw. Judging from the recent discussion
> about oo(though I don't understand details),the change seems to be
> needed in order to make inheritance functionality really useful. 

What would happen is that all the logical attributes would be shifted
over, and a new column added using ADD COLUMN would be put in its place.
Seems it would work fine.



--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: ALTER TABLE DROP COLUMN

От
The Hermit Hacker
Дата:
On Sun, 11 Jun 2000, Bruce Momjian wrote:

> > > -----Original Message-----
> > > From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> > > 
> > > >> 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
> > >
> > 
> > Hmm,I've received no pg-ML mails for more than 1 day.
> > What's happened with pgsql ML ? 
> 
> Tom says there are tons of messages in the hub.org mail queue, but they
> are not being delivered.

I was out for the past 4 days taking a little girl camping for her b-day
... great weekend, but we had a process run rampant over the weekend that
caused the loadavg to skyrocket.  For anyone that has ever used sendmail,
they will know that a high load will cause sendmail to essentially shut
itself down, queuing only up to a certain point, refusing connections
after that ... queuing is at a loadavg of 15, refusing connections at 20,
the machine was slightly higher then that ...

Just checked the queue, and now that the load is back down, the queue is
pretty much flushed out again ...