Tom Lane wrote: > I've been playing around with different alternatives for solving the > problem of toast-pointer OIDs, but I keep coming back to the above as > being the least invasive and most robust answer. There are two basic > ways that we could do it: pass the OID to use to the toast logic, which > would require adding a parameter to heap_insert and a number of other > places; or add a field to struct Relation that says "when inserting a > TOAST pointer in this relation, use this OID as the toast-table OID > value in the pointer, even if that's different from what the table's OID > appears to be". The latter seems like less of a notational change, so > I'm leaning to that, but wanted to see if anyone prefers the other. > > We could avoid this hackery if there were a way for Relation structs to > point at either the old or the new physical relation (relfilenode); > then we'd not need the transient "new heap" relation during CLUSTER/VF, > which would be good for reducing catalog churn. I've concluded that > that's too large a change to undertake for 9.0, but it might be > interesting to try in the future. So I'd prefer that what we do for > now touch as little code as possible so as to be easy to revert; hence > I'm not wanting to change heap_insert's signature.
I don't think any of this affects pg_migrator, but if it does, please let me know. When I hear TOAST and OID used in the same sentence, my ears perk up. :-) -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
