On Tue, 21 May 2002 11:53:04 -0400, Tom Lane <[EMAIL PROTECTED]> wrote: >The system tables that have OIDs will certainly continue to have OIDs.
That's clear. I should have written: "... rip out oids from tuple headers of system tables." >Ugh. While certainly we should have been using accessor >macros for that, I'm not sure I want to try to change it. I already did this for xmin, xmax, cmin, cmax, and xvac (see my patch posted 2002-05-12). >If OID is made to be the last fixed-offset field, instead of the first, That would introduce some padding. >then this approach would be fairly workable. Actually I'd still use >just one struct definition, but do offsetof() calculations to decide >where the null-bitmap starts. ... and for calculating the tuple header size. >> Decouple on-disk format from in-memory structures, use >> HeapTupleHeaderPack() and HeapTupleHeaderUnpack() to store/extract >> header data to/from disk buffers. Concurrency? > >Inefficient, Just to be sure: You mean the CPU cycles wasted by Pack() and Unpack()? >I'd be afraid to use a conversion-in-place tool for this sort of thing. Me too. No, not in place! I thought of a filter reading an old format data file, one page at a time, and writing a new format data file. This would work as long as the conversions don't cause page overflow. No comment on a planned 7.3 timeframe? :-( Servus Manfred ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html