On 14/10/14 19:03, Andrea Faulds wrote: >>> I don't see why you'd have two code paths. If you need bigints and they >>> >> are not there, then you just fail, like with any extension your code >>> >> needs and is not installed. If it's there, you just continue working. >>> >> All the code existing now doesn't need bigints, and even in the future >>> >> most code won't need it. But for some code it would just work like >>> >> before, only with unlimited range now. >> > >> > 'bitinteger!' >> > I'm still waiting to see how we handle 'BIGINT' under this rfc since >> > that is something every database driver does need to handle. > If you mean 64-bit ints, this RFC enables them to work on 32-bit too with > exactly the same semantics. No more float overflow. On a 64-bit machine, > they’re IS_LONG internally, and on 32-bit machines they’re IS_BIGINT, but the > user doesn’t need to worry, they both act the same. > > Assuming I actually get round to updating the DB drivers.
If a 64bit build of PHP is using a simple integer key for a BIGINT key from the database, what will be the equivalent on a 32bit build? It may be that we have to add code to the DB drivers to ensure that BIGINT remains a standard string conversion on both platforms in order to maintain consistent results. One being a simple integer key and the other a GMP based key IS a problem when the key is constructed from other shifted elements. This may be no more complicated than happens now, but is a real life situation that needs a consistent result. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
