Hi,
would it not be easier to use our UUID instead? I have patch in my tree,
will try to extract it...
Thanks,
Alex
Guillaume Cottenceau schrieb:
"Hillel" <hillel 'at' ecommunicate.biz> writes:
Hi,
Guillaume I agree it's not so clear from the documentation below, but as far
as I know the CTID is the physical position of the row inside the heap.
Every UPDATE and some VACUUM operations can affect it.
Even if the CTID may be stable over a DELETE as of today, some future
storage engine development (like HOT enhancements) may put an end to that.
In general, the CTID is not guaranteed to remain the same unless you hold a
FOR UPDATE lock on the row.
True, though the net result is really similar to the previous one
with OIDs. I guess it boils down to knowing why OID why chosen
over a proper SERIAL column in the first place, and I don't know
the reason for that (I could find no relevant information in the
mailing-list archive; though, I guess the reasoning was to have a
unique way of creating the kannel DLR table, not one per database
engine; however, on that question, the approach proved its limit,
IMHO). If OID was fine, I think CTID is fine, since it has a
similar behaviour (and I don't think concurrent UPDATEs on the
dlr table is a supported usage pattern). If we want to be safe,
and we can afford a different way of creating tables per database
engine (which is already the case btw, due to the INT(10)
difference) then of course, using a proper SERIAL column is the
best decision.
