Re: PATCH: Postgresql Patch

"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