Re: PATCH: Postgresql Patch

you didn't get the point. UUID is generated for each msg in kannel and 
kannel depends all over the place that this UUID is unique (see: store, 
queue ...). UUID is already in place IMHO we don't need yet another 
SERIAL for this purpose.

Thanks,
Alex

Marius Huysamen schrieb:
>  
> I prefer Hillel's implementation using SERIAL. It's guaranteed to be
> unique within the database. User/application generated unique id's
> aren't a good idea, and have no advantage over a database SERIAL in this
> instance.
> 
> Alexander Malysh wrote:
>  > Hi Enver,
>  >
>  >
>  > Enver ALTIN schrieb:
>  >> 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.
>  >
>  > this is not true. UUID is to 99% unique even in a cluster. We have log
>  > tabel in the DB with over 500K inserts per day and UUID will be
>  > generated not only by one instance and I never seen clash since 2years.
>  >
>  >>
>  >> Personally I like the serial column approach.
>  >>
>  >> -HTH
>  >>
>  >> On Tue, Jun 24, 2008 at 12:45 PM, Alexander Malysh
>  >> <[email protected] <mailto:[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
>  >> <http://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
>  >
>  >
>  
> 
> **********************************************************************
> ---------
> NOTICE
> ---------
> 
> This message (including attachments) contains privileged and 
> confidential information intended only for the person or entity to which 
> it is addressed.
> 
> Any review, retransmission, dissemination, copy or other use of, or 
> taking of any action in reliance upon this information by persons or 
> entities other than the intended recipient, is prohibited.
> 
> If you received this message in error, please notify the sender 
> immediately by e-mail, facsimile or telephone and thereafter delete the 
> material from any computer.
> 
> Metropolitan Health Group, its subsidiaries or associates, does not 
> accept liability for any personal views expressed in this message.
> 
> *Metropolitan Health Group*
> PO Box 4313 Cape Town 8000 Tel: (021) 480 4511 Fax: (021) 480 4535 
> www.mhg.co.za <http://www.mhg.co.za/>  
> 
> **********************************************************************
>