Hi Frederik, Can you give some rough estimates on how much time we still have until this 64bit issue comes up?
Thanks, Igor On Fri, May 20, 2011 at 10:42 PM, Frederik Ramm <[email protected]> wrote: > Hi, > > not long now and we'll have our nodes IDs exceed the magical 2^31-1 > limit, a time at which many applications will doubtless experience their own > little version of the year 2000 problem ;) > > I have modified osm2pgsql to support 64 bit IDs (int8/bigint on > PostgreSQL). The modified version is a branch called osm2pgsql-64, in the > same directory as the original osm2pgsql source code. > > I didn't dare to simply commit my changes to osm2pgsql proper but in > theory, if you don't set the OSMID64 compile flag, the new version should > behave exactly as the old. > > osm2pgsql used to make use of the "intarray" contrib module in slim mode, > Since that module does not support the int8/bigint data type, I had to > change things to use PostgreSQL's built-in array capabilites. > > For reasons I do not fully understand, the intarray module is now actually > harmful to this new version of osm2pgsql because it seems to keep the > built-in array methods from using indexes. This means that while the old > osm2pgsql required that you load _int.sql, the new osm2pgsql will actually > complain if you have done that. > > It would be great if a few people could test-drive the new osm2pgsql (in 32 > or 64 bit ID mode), and fix/report any bugs they might find. I hope that > everything is fine, I made no major blunders, and we can soon replace the > existing implementation with the no-intarray 64-bit-capable version. > > Bye > Frederik > > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/dev >
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
