I guess this may wreak havoc if someone insane decides to connect multiple bearerbox instances to a single database server, because there is little chance that two different bearerbox instances creating a not-so-universally-unique-ID that may clash.
Personally I like the serial column approach. -HTH On Tue, Jun 24, 2008 at 12:45 PM, Alexander Malysh <[EMAIL PROTECTED]> wrote: > 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. >> >> > > -- Enver
