| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Neil Conway <neilc(at)samurai(dot)com> |
| Cc: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Jeff Davis <jdavis-pgsql(at)empires(dot)org>, jeff sacksteder <jsacksteder(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: unsigned types |
| Date: | 2005-10-18 21:47:35 |
| Message-ID: | 14114.1129672055@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Neil Conway <neilc(at)samurai(dot)com> writes:
> We could improve on this by reordering fields on-disk to reduce
> alignment/padding requirements, during CREATE TABLE. We'd need to be
> sure to present the same column order back to the client application, of
> course, but that should be possible. The notion of a "physical column
> number" (on-disk position of the column) as well as a "logical column
> numer" (position of the column in the table -- e.g. in SELECT *
> expansion) would also make it easy to implement column reordering in
> ALTER TABLE, which has been requested a few times.
And it's been looked at a few times, and rejected as being far too
bug-prone. The number of ways to screw up by using physical column
number where you should have used logical, or vice versa, is daunting.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Johan Wehtje | 2005-10-18 21:53:35 | Re: A good client |
| Previous Message | Onyx | 2005-10-18 21:35:17 | PostgreSQL on Dual Processors, Dual-Core AMD Chips |