Thomas Hallgren <[EMAIL PROTECTED]> writes:
> When making PL/Java dynamically adapt to the setting of
> integer-datetimes, I too was bitten by this bug. Is it safe to assume
> that the fix for this will arrive in 8.1.0?
I believe Teodor already committed the change in CVS HEAD.
Teodor Sigaev wrote:
Urgh. This is clearly a bug. All the code in utils/adt seems to be
correctly set up to treat TimeADT as an integral value, but then the two
macros quoted are converting the value to float8 and back again ... so
what's actually on disk is the float8 equivalent of what the int6
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> We'll obviously want to fix this going forward for efficiency reasons,
>> but it's an initdb-forcer because it'll change the on-disk
>> representation of time columns. So we can't change it in 8.0 or before.
> So, will we do it? I can do, but I don't k
Urgh. This is clearly a bug. All the code in utils/adt seems to be
correctly set up to treat TimeADT as an integral value, but then the two
macros quoted are converting the value to float8 and back again ... so
what's actually on disk is the float8 equivalent of what the int64 value
is supposed t
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> It looks consistently, but for time (from utils/date.h):
> ifdef HAVE_INT64_TIMESTAMP
> typedef int64 TimeADT;
> #else
> typedef float8 TimeADT;
> #endif
> #define TimeADTGetDatum(X)Float8GetDatum(X)
> #define DatumGetTimeADT(X)((TimeADT
Hi!
I work on memory leaks during creation index on time/timestamp column using GiST
and found follow problem (?):
For timestamp storage and defines are defined as (from utils/timestamp.h):
#ifdef HAVE_INT64_TIMESTAMP
typedef int64 Timestamp;
#define TimestampGetDatum(X) Int64GetDatum(X)
#define
