On Friday 01 July 2005 09:55, Richard Lynch wrote: > There are innumerable on-line forums that (incorrectly) state that an > OID could be returned that is not connection-specific, so two HTTP > requests in parallel would criss-cross OIDs. > > This is patently false, and any user of PostgreSQL can demonstrate that > in minutes (okay, an hour for a newbie) of coding. Someone with more time than me can go search for those above-mentioned forums and judge for themselves. However regardless of whether OIDs cross-pollination is possible or not ... > OIDs *can* get re-used *IF* you end up having more than 32-bits (2 > billion plus) of objects in the lifetime of your application. > > For normal usage, that ain't a big problem, honestly... > > Though I should have stated it for the record, cuz maybe the OP has a > site where 2 BILLION INSERTs are gonna happen. ... 4 billion (I'm assuming the postgresql guys are smart enough to use unsigned integers) isn't really as much as it looks. Remember this is shared amongst all the tables in your database making these oids even more of a precious resource ... > The solutions there are the same as for not having OID in the first > place -- Have some other unique identifier you generate yourself in the > INSERT, or use that *with* the OID to be 100% certain you get back the > same row from your 2 billion plus data set. ... and that's exactly what sequences are for. And that's why using oids for a unique id is not a smart choice when sequences are available and were designed explicitly to provide unique ids. > If there's a reliable, web-safe, connection-dependent way of getting > the sequence ID used in an INSERT, it sure ain't documented, and I've > never seen it discussed on the PostgreSQL list (which I dropped off > awhile ago, so maybe it's something new). I have already given an example(!) > Though that also limits you to 2 billion plus records per table -- The current versions of postgresql allows for 8 byte sequences which provides 1.8E19 unique ids. Now *this* will take some serious database work to cycle through all the ids. Assuming you generate a million ids per second it will take only half a million years for you to start worrying about running out of ids. But by that time I'm sure you would be more worried about the billennium bug :) > If you are dealing in 2 billion object PostgreSQL databases, and you > don't know all this already, you're in DEEP trouble... I think I'll be quite safe as I'm using sequences ;-) -- Jason Wong -> Gremlins Associates -> www.gremlins.biz Open Source Software Systems Integrators * Web Design & Hosting * Internet & Intranet Applications Development * ------------------------------------------ Search the list archives before you post http://marc.theaimsgroup.com/?l=php-general ------------------------------------------ New Year Resolution: Ignore top posted posts -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
