| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Hannu Krosing <hannu(at)tm(dot)ee> |
| Cc: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, pg(at)fastcrypt(dot)com, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Neil Conway <neilc(at)samurai(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: ALTER COLUMN/logical column position |
| Date: | 2003-11-20 15:26:59 |
| Message-ID: | 4272.1069342019@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)tm(dot)ee> writes:
> You are just shifting the interface problems to a place needing way more
> changes in the backend. There will be some problems either way.
Exactly. I'm considerably more worried about breaking out-of-the-way
places in the backend than I am about what order someone's admin tool
presents the columns in.
> Btw, most of these concerns (and more) were already iterated when DROP
> column was done causing gaps in attnum. There were a lot of doomsday
> profecies, but in the end it went quite smoothly.
That is a good comparison point. I'm inclined to think that we should
do it in a way that minimizes backend changes. The way to do that is
to keep attnum with its current definition (physical position) and add
a new column for the logical position, which only a small number of
places will need to care about.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-11-20 15:39:24 | Re: logical column position |
| Previous Message | Tom Lane | 2003-11-20 15:18:25 | Re: tsearch2 patch for 7.4.1 |