Re: OID wraparound: summary and proposal

Jan Wieck <JanWieck(at)yahoo(dot)com> writes:
> Keep also in mind that actually the uniqueness of Oid's
> across all tables is used by TOAST to determine that a
> toasted value found in the new tuple is the same than in the
> old one on heap_update() or not.
> It's no big deal, some additional checks of the va_toastrelid
> beeing the same as the target relations toast relation should
> do it.

Good point.

> Now since toast needs the row Oid allways, I think the idea
> of making Oid's in user tables optional is dead.

Why? I see where it's looking at the main-row OID and attno to decide
if it's the same value or not, but this seems strange and wrong. Why
doesn't it just compare va_toastrelid and va_valueid? Considering that
the main point of this comparison is to distinguish values associated
with different versions of the same row, neither main row OID nor
attribute number seem helpful. I don't see why we expend space on
storing va_rowid + va_attno at all.

BTW, I've already completed implementing optional OIDs, so I'm not
going to give up the idea lightly at this point ;-)

regards, tom lane