Manfred Koizar <[EMAIL PROTECTED]> writes: > That was one of the possible solutions I thought of, unfortunately the > one I'm most afraid of. Not because I think it's not the cleanest > way, but I don't (yet) feel comfortable enough with the code to rip > out oids from system tables.
The system tables that have OIDs will certainly continue to have OIDs. I suppose the messiest aspect of that solution would be changing all the places that currently do "tuple->t_data->t_oid". If OID is not at a fixed offset in the tuple then it'll be necessary to change *all* those places. Ugh. While certainly we should have been using accessor macros for that, I'm not sure I want to try to change it. > Other possible implementations would leave the oid in the tuple > header: > . typedef two structs HeapTupleHeaderDataWithOid and > HeapTupleHeaderDataWithoutOid, wrap access to *all* HeapTupleHeader > fields in accessor macros/functions, give these accessors enough > information to know which variant to use. If OID is made to be the last fixed-offset field, instead of the first, 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. > Decouple on-disk format from in-memory structures, use > HeapTupleHeaderPack() and HeapTupleHeaderUnpack() to store/extract > header data to/from disk buffers. Concurrency? Inefficient, and you'd have problems still with the changeable fields (t_infomask etc). >> As usual, the major objection to any such change is losing the chance >> of doing pg_upgrade. But we didn't have pg_upgrade during the 7.2 >> cycle either. > I thought, it is quite common to need pg_dump/restore when upgrading > between releases. Yes, and we get loud complaints every time we require it... > Anyway, as long as our changes don't make heap tuples larger, it > should be possible to write a tool that converts version x data files > to version y data files. I've done that before (not for PG though) > and I know it's a lot of work, but wouldn't it be great for the PG > marketing department ;-) I'd be afraid to use a conversion-in-place tool for this sort of thing. If it crashes halfway through, what then? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly