Re: [HACKERS] USECS_* constants undefined with float8 timestamps?

2011-08-12 Thread Bruce Momjian
Robert Haas wrote:
 On Fri, Jul 29, 2011 at 11:18 AM, Johann 'Myrkraverk' Oskarsson
 joh...@2ndquadrant.com wrote:
  Hi all,
 
  I just noticed that the USECS_* constants are not defined when the server
  is compiled without integer dates and timestamps.
 
  Explicitly, timestamp.h is
 
  #ifdef HAVE_INT64_TIMESTAMP
  #define USECS_PER_DAY   INT64CONST(864)
  #define USECS_PER_HOUR  INT64CONST(36)
  #define USECS_PER_MINUTE INT64CONST(6000)
  #define USECS_PER_SEC   INT64CONST(100)
  #endif
 
  Is there a particular reason for this? ?Even with float8 timestamps
  there are uses for these constants in extensions.
 
 I don't see any particular reason not define them unconditionally.

Well, they are only used by integer dates, so why expand their
visibility?  The define does make it clear how they are used.  I suppose
if someone wanted to use them outside that case, we could open them up. 
It is true that with integer dates now the default, we might find that
someone introduces compile problems by using them outside the integer
dates scope.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] USECS_* constants undefined with float8 timestamps?

2011-08-12 Thread Johann 'Myrkraverk' Oskarsson
Bruce Momjian br...@momjian.us writes:

 Robert Haas wrote:
 On Fri, Jul 29, 2011 at 11:18 AM, Johann 'Myrkraverk' Oskarsson
 joh...@2ndquadrant.com wrote:
 
  I just noticed that the USECS_* constants are not defined when
  the server is compiled without integer dates and timestamps.
[snip]
 I don't see any particular reason not define them unconditionally.

 Well, they are only used by integer dates, so why expand their
 visibility?  The define does make it clear how they are used.  I
 suppose if someone wanted to use them outside that case, we could
 open them up. It is true that with integer dates now the default, we
 might find that someone introduces compile problems by using them
 outside the integer dates scope.

I found a use for them in PL/Java which detects at run-time whether
the server is using floating point or integer dates.  The simplest way
was just to use magic numbers instead on the off chance it's compiled
with a server using float dates.


-- 
   Johann Oskarssonhttp://www.2ndquadrant.com/|[]
   PostgreSQL Development, 24x7 Support, Training and Services  --+--
  |
   Blog: http://my.opera.com/myrkraverk/blog/


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] USECS_* constants undefined with float8 timestamps?

2011-08-12 Thread Bruce Momjian
Johann 'Myrkraverk' Oskarsson wrote:
 Bruce Momjian br...@momjian.us writes:
 
  Robert Haas wrote:
  On Fri, Jul 29, 2011 at 11:18 AM, Johann 'Myrkraverk' Oskarsson
  joh...@2ndquadrant.com wrote:
  
   I just noticed that the USECS_* constants are not defined when
   the server is compiled without integer dates and timestamps.
 [snip]
  I don't see any particular reason not define them unconditionally.
 
  Well, they are only used by integer dates, so why expand their
  visibility?  The define does make it clear how they are used.  I
  suppose if someone wanted to use them outside that case, we could
  open them up. It is true that with integer dates now the default, we
  might find that someone introduces compile problems by using them
  outside the integer dates scope.
 
 I found a use for them in PL/Java which detects at run-time whether
 the server is using floating point or integer dates.  The simplest way
 was just to use magic numbers instead on the off chance it's compiled
 with a server using float dates.

OK, that is a good reason.  Done for PG 9.2.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] USECS_* constants undefined with float8 timestamps?

2011-07-29 Thread Johann 'Myrkraverk' Oskarsson
Hi all,

I just noticed that the USECS_* constants are not defined when the server
is compiled without integer dates and timestamps.

Explicitly, timestamp.h is

#ifdef HAVE_INT64_TIMESTAMP
#define USECS_PER_DAY   INT64CONST(864)
#define USECS_PER_HOUR  INT64CONST(36)
#define USECS_PER_MINUTE INT64CONST(6000)
#define USECS_PER_SEC   INT64CONST(100)
#endif

Is there a particular reason for this?  Even with float8 timestamps
there are uses for these constants in extensions.


-- 
   Johann Oskarssonhttp://www.2ndquadrant.com/|[]
   PostgreSQL Development, 24x7 Support, Training and Services  --+--
  |
   Blog: http://my.opera.com/myrkraverk/blog/


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] USECS_* constants undefined with float8 timestamps?

2011-07-29 Thread Robert Haas
On Fri, Jul 29, 2011 at 11:18 AM, Johann 'Myrkraverk' Oskarsson
joh...@2ndquadrant.com wrote:
 Hi all,

 I just noticed that the USECS_* constants are not defined when the server
 is compiled without integer dates and timestamps.

 Explicitly, timestamp.h is

 #ifdef HAVE_INT64_TIMESTAMP
 #define USECS_PER_DAY   INT64CONST(864)
 #define USECS_PER_HOUR  INT64CONST(36)
 #define USECS_PER_MINUTE INT64CONST(6000)
 #define USECS_PER_SEC   INT64CONST(100)
 #endif

 Is there a particular reason for this?  Even with float8 timestamps
 there are uses for these constants in extensions.

I don't see any particular reason not define them unconditionally.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers