From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: RFC: Restructuring pg_aggregate |
Date: | 2002-04-12 02:54:01 |
Message-ID: | 24004.1018580041@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-04-12 03:25:07 | Re: 7.3 schedule |
Previous Message | Christopher Kings-Lynne | 2002-04-12 02:33:44 | Re: command.c breakup |