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
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
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 know: Is
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
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)
