"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. -- Guillaume Cottenceau, MNC Mobile News Channel SA, an Alcatel-Lucent Company Av. de la Gare 10, 1003 Lausanne, Switzerland - direct +41 21 317 50 36
