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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +