On Sun, 23 Sep 2012 17:31:38 +0100, Adam D. Barratt wrote:
> On Sun, 2012-09-23 at 18:19 +0200, David Paleino wrote:
> > On Sun, 23 Sep 2012 17:11:08 +0100, Adam D. Barratt wrote:
> > > On Sun, 2012-09-23 at 09:24 +0200, David Paleino wrote:
> > > > Please unblock package osm2pgsql.
> > > >
> > > > Latest version (which should've been -2, but I've messed up with the
> > > > changelog, and didn't notice it was -3 only after the dput) fixes RC bug
> > > > #687965.
> > >
> > > The bug report indicates that database tables would need to be rebuilt
> > > in line with the 32- to 64-bit change. Would that happen automatically,
> > > or is it something that users are expected to do after upgrading?
> >
> > They're expected to do that on their own.
> >
> > However, I noticed that osm2pgsql/testing already used BIGINT columns for
> > osm_id (BIGINT == int_8), maybe for some other bug of the software (which
> > created 64 bit columns even though one asked for 32 bit). I haven't checked
> > the version in stable.
>
> 0.69+r20104-2 (squeeze) has:
>
> #define CREATE_PLACE_TABLE \
> "CREATE TABLE place (" \
> " place_id BIGINT," \
> " osm_type CHAR(1) NOT NULL," \
> " osm_id BIGINT NOT NULL," \
>
> That would imply that the field is already 64-bit even in stable?
Uhm. I missed one "tiny" bit.
My patch fixes also output-gazetteer.c -- which already used BIGINT, but
output-pgsql.c was using POSTGRES_OSMID_TYPE. That means 32 bit in
stable/testing, and now 64 bit in unstable.
Should I upload a new version with a notice about the database migration?
Thanks,
David
--
. ''`. Debian developer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 ----|---- http://deb.li/dapal
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
Attachment:
signature.asc
Description: PGP signature