According to the release notes of postgres 8.4, 64-bit integer datetimes is now the default. The --disable-integer-datetimes option is provided for backwards compatibility. Reproducible: Always
Proposed patch below (and colored here: http://pb.lericson.se/p/xuqosN/)... USE-flag naming is so-so, but still recognizable if you actually used the old one. Any suggestions? diff -ur ./metadata.xml /usr/portage/dev-db/postgresql-base/metadata.xml --- ./metadata.xml 2009-10-27 22:32:48.000000000 +0100 +++ /usr/portage/dev-db/postgresql-base/metadata.xml 2008-08-05 19:05:45.000000000 +0200 @@ -3,8 +3,7 @@ <pkgmetadata> <herd>postgresql</herd> <use> - <flag name='pg-oldintdatetime'>Enable --disable-integer-datetimes configure - option, which changes PG to use 32-bit integers for timestamp storage - (default for 8.3 and older)</flag> + <flag name='pg-intdatetime'>Enable --enable-integer-datetimes configure + option, which changes PG to use 64-bit integers for timestamp storage</flag> </use> </pkgmetadata> diff -ur ./postgresql-base-8.4.1.ebuild /usr/portage/dev-db/postgresql-base/postgresql-base-8.4.1.ebuild --- ./postgresql-base-8.4.1.ebuild 2009-10-28 16:41:12.000000000 +0100 +++ /usr/portage/dev-db/postgresql-base/postgresql-base-8.4.1.ebuild 2009-10-24 14:37:53.000000000 +0200 @@ -21,7 +21,7 @@ linguas_hr linguas_hu linguas_it linguas_ko linguas_nb linguas_pl linguas_pt_BR linguas_ro linguas_ru linguas_sk linguas_sl linguas_sv linguas_tr linguas_zh_CN linguas_zh_TW" -IUSE="doc kerberos nls pam pg-oldintdatetime readline ssl threads zlib ldap ${IUSE_LINGUAS}" +IUSE="doc kerberos nls pam pg-intdatetime readline ssl threads zlib ldap ${IUSE_LINGUAS}" RESTRICT="test" wanted_languages() { @@ -82,7 +82,7 @@ $(use_with kerberos gssapi) \ "$(use_enable nls nls "$(wanted_languages)")" \ $(use_with pam) \ - $(use_enable !pg-oldintdatetime integer-datetimes ) \ + $(use_enable pg-intdatetime integer-datetimes ) \ $(use_with ssl openssl) \ $(use_enable threads thread-safety) \ $(use_enable threads thread-safety-force) \
...of course one can always make the "old" (pg-intdatetime) flag enabled by default. Not much of a difference except you'd probably want this on, always.
I think the pg-oldintdatetime solution is the best. Note thought that with "--disable-integer-datetimes" you don't get 32-bit integers for timestamps, you get double precision floating-point ([1]). [1] http://www.postgresql.org/docs/8.4/static/datatype-datetime.html
Actually pg-olddatetime would be even better.
EAPI=1 provides IUSE defaults, what's wrong with just adding +pg_intdatetime in there? This will enable it by default with no user intervention and keep won't add inverse semantics. What is 'pg-oldintdatetime' supposed to mean anyway? Does --disable-integer-datetimes switch to floating point datetime storage? If so, pg-oldintdatetime should be called 'pg-floatdatetime' if any. I'd vote for adding pg_intdatetime in IUSE defaults anyway.
(In reply to comment #5) > EAPI=1 provides IUSE defaults, what's wrong with just adding +pg_intdatetime in > there? This will enable it by default with no user intervention and keep won't > add inverse semantics. > What is 'pg-oldintdatetime' supposed to mean anyway? > Does --disable-integer-datetimes switch to floating point datetime storage? If > so, pg-oldintdatetime should be called 'pg-floatdatetime' if any. > I'd vote for adding pg_intdatetime in IUSE defaults anyway. > This is what I initially proposed. But the thing is, integer timestamps is now the default and --disable-integer-datetimes is a legacy option. So I think it makes more sense to have an option (initially disabled) that would enable the legacy behavior than having an option (initially enabled) to enable the default behavior. This way we encourage users to use interger timestamps whereas with +pg_intdatetime some users might start wondering what's this use flag that's being enabled by default. That's why I now propose a new use flag pg-legacytimestamps which is the negation of pg_intdatetime. I have already posted a patch (in bug 285475) that changes that.
pg_legacytimestamp is fine (or pg_floattimestamp), but please no pg_oldintdatetimestamp I would be a bit cautions with this, while in most cases indeed int64 is used, it's not a rule (it may be intended or actually a bug): from interfaces/ecpg/pgtypeslib/dt.h for instance: #ifdef HAVE_INT64_TIMESTAMP typedef int32 fsec_t; #else typedef double fsec_t; Which is not what everyone would expect.
pg_legacydatetime that is - with USE flag description clearly stating that it falls back to float8/double time stamp storage.
+ 07 Jan 2010; Patrick Lauer <patrick@gentoo.org> + +postgresql-base-8.4.2-r1.ebuild, metadata.xml: + Changing pg-intdatetime to pg_legacytimestamp useflag since upstream + changed defaults and deprecated the old behaviour. See #285475 #290535
Changing between pg-intdatetime and !pg-intdatetime means your server will no longer start, so the default should not have been changed in the ebuild without a big fat warning...
Actually postgresql-server needs to be rebuilt *always* this change is done in postgresql-base (so that server libs and server executables have the same datetime format for database cluster). Therefore I propose the following solution: - move postgresql-server to EAPI-2 (to get USE deps) - introduce pg_legacytimestamp USE flag in postgresql-server - add USE dependency ~dev-db/postgresql-base-${PV}:${SLOT}[pg_legacytimestamp=] I think it's worth reopening this bug (and I do it now) as simple upgrade even from 8.4.2 renders server in inconsistent state (and non working with existing database clusters).
You're probably right, but that's not what I meant. Install postgresql-{base,server} with the default USE="-pg-intdatetime", create a database, rebuild postgresql-{base,server} with the new default USE="-pg_legacytimestamp", try to start. Even though -base and -server are built to matching flags, this won't work.
Note that I didn't say you're wrong :) Of course at least pkg_postinst message is needed. It's actually quite severe as databases need to be exported and recreated again from backup in order to migrate to integer timestamps - and it's not really straighforward procedure. I even think it's worth adding in pkg_setup even with ebeep as one needs to export database before upgrading postgresql. Good thing is actual issue is clearly stated in postgresql logs when one attempts to use server incompatible with database cluster so it's not like users (database administrators) are left helpless.
(In reply to comment #13) I was just running into this trap on a (thank good) non production server (except heating at home and collection some weather data :-) ). Postgresql's thought behind minor release upgrades always was, that you just recompile the server and "A dump/restore is not required for those running 8.4.X" (from the Changelog) What we have here now is, that a dump restore _IS_ required even for a minor update. Pls do not do that. Off course I can switch back to 8.4.2 in a glimpse. But I expect a minor update to work even on a production server with very short outage. I'd propose NOT breaking things when doing a minor update. It's getting colder now, I better reemerge 8.4.2 now ;-)
I've added some elog notices and added the useflag to -server so it becomes really obvious. Hope that's enough to make you happy :)