Re: RFC: Restructuring pg_aggregate
От | Dave Page |
---|---|
Тема | Re: RFC: Restructuring pg_aggregate |
Дата | |
Msg-id | FED2B709E3270E4B903EB0175A49BCB1293387@dogbert.vale-housing.co.uk обсуждение исходный текст |
Ответ на | RFC: Restructuring pg_aggregate (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 12 April 2002 03:54 > To: Bruce Momjian > Cc: Hiroshi Inoue; Christopher Kings-Lynne; > pgsql-hackers@postgresql.org > Subject: Re: RFC: Restructuring pg_aggregate > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I think that is why Tom was suggesting making all the column values > > NULL and removing the pg_attribute row for the column. > > That was not my suggestion. > > > With a NULL value, it > > doesn't take up any room in the tuple, and with the pg_attribute > > column gone, no one will see that row. The only problem is > the gap in > > attno numbering. How big a problem is that? > > You can't do it that way unless you're intending to rewrite > all rows of the relation before committing the ALTER; which > would be the worst of both worlds. The pg_attribute row > *must* be retained to show the datatype of the former column, > so that we can correctly skip over it in tuples where the > column isn't yet nulled out. > > Hiroshi did this by renumbering the attnum; I propose leaving > attnum alone and instead adding an attisdropped flag. That > would avoid creating a gap in the column numbers, but either > way is likely to affect some applications that inspect pg_attribute. Applications like pgAdmin that inspect pg_attribute are being seriously hacked to incorporate schema support anyway for 7.3. Personnally I'd be glad to spend some time re-coding to allow for this, just to not have to answer the numerous 'how do I drop a column' emails I get reguarly. Regards, Dave.
В списке pgsql-hackers по дате отправления: