Bug 76999 - [PATCH] Support for alternative date/time datatype
Summary: [PATCH] Support for alternative date/time datatype
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Palle Girgensohn
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-02 10:20 UTC by Christian Ullrich
Modified: 2005-04-14 00:17 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Ullrich 2005-02-02 10:20:11 UTC
PostgreSQL supports the use of 64-bit integer values for date/time types instead of the default double. This option is not yet offered by the port Makefiles. The supplied patch adds support for this feature to the postgresql74-server port.

Fix: 

.  if defined(SERVER_ONLY) && defined(WITH_PAM)
 CONFIGURE_ARGS+=--with-pam
@@ -114,10 +113,6 @@
 INSTALL_TARGET=        install
 .  else
 INSTALL_TARGET=        install-strip
-.  endif
-
-.  if defined(WITH_INTDATE)
-CONFIGURE_ARGS+=       --enable-integer-datetimes
 .  endif

 .  if defined(WITH_MIT_KRB5)--cl8xnjB2ws2PEjUxgcZbLumfFk7u3V4NAekWGzhM0yBgSgRK
Content-Type: text/plain; name="file.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="file.diff"

--- /usr/ports/databases/postgresql74-server/Makefile   Wed Feb  2 11:55:57 2005
+++ /usr/ports/databases/postgresql74-server/Makefile.orig      Wed Feb  2 11:59:39 2005
@@ -86,7 +86,6 @@
 OPTIONS+=      TESTS "Allows the use of a \"check\" target" off
 .  endif
 OPTIONS+=      DEBUG "Builds with debugging symbols" off
-OPTIONS+=      INTDATE "Builds with 64-bit integer date/time type" off
Comment 1 Anton Berezin freebsd_committer freebsd_triage 2005-02-02 10:59:36 UTC
Responsible Changed
From-To: freebsd-ports-bugs->girgen

Over to maintainer.
Comment 2 Christian Ullrich 2005-02-02 18:51:07 UTC
Well, it would add that support, but the patch obviously is reversed.
I can't understand how that happened. I'm sorry.

-- 
Christian Ullrich
Comment 3 Palle Girgensohn 2005-02-02 22:00:12 UTC
Changing this will require a dump/restore... There must be some sort of 
warning about this in the port.

Have you any idea why it is not on by default? Fresh code, not as well 
tested?

/Palle
Comment 4 Christian Ullrich 2005-02-03 18:58:25 UTC
> Have you any idea why it is not on by default? Fresh code, not as well 
> tested?

No, it's been in there since 7.3. The reason is that timestamps
stored as doubles degrade in precision with increasing distance
from "zero", as the exponent rises and significant digits are lost.
It's in the PostgreSQL docs, in "Date/Time Types".

Storing them as integer values, however, avoids that, at the price
of a limited range. Limited, that is, to 290000 years into the
future.

-- 
Christian Ullrich
Comment 5 Palle Girgensohn 2005-02-03 22:49:42 UTC
--On torsdag, februari 03, 2005 19.58.25 +0100 Christian Ullrich 
<chris@chrullrich.de> wrote:

>> Have you any idea why it is not on by default? Fresh code, not as well
>> tested?
>
> No, it's been in there since 7.3. The reason is that timestamps
> stored as doubles degrade in precision with increasing distance
> from "zero", as the exponent rises and significant digits are lost.
> It's in the PostgreSQL docs, in "Date/Time Types".
>
> Storing them as integer values, however, avoids that, at the price
> of a limited range. Limited, that is, to 290000 years into the
> future.

heh :-)  Well, that's probably enough for most ppl. But it's cool to have a 
timestamp that goes on forever, but with less precision. It is a very good 
idea, indeed :)
Comment 6 Palle Girgensohn freebsd_committer freebsd_triage 2005-04-14 00:17:15 UTC
State Changed
From-To: open->closed

Committed. Thanks!