Skip site navigation (1) Skip section navigation (2)

Re: pgsql: Add time/date macros for code clarity: #define

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Add time/date macros for code clarity: #define
Date: 2005-07-21 04:55:45
Message-ID: 200507210455.j6L4tjQ14343@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-committers
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >>> #define DAYS_PER_YEAR   365.25
> >>> #define MONTHS_PER_YEAR 12
> >>> #define DAYS_PER_MONTH  30
> >>> #define HOURS_PER_DAY   24
> >> 
> >> Considering that only one of these four is actually an accurate
> >> constant, I have to question the usefulness of this.
> 
> > Yea, the problem is that these non-absolute constants are littered all
> > through the code, so it is best to have them at least in one place.  I
> > will add a comment marking the non-accurate ones more clearly.
> 
> Unless you comment every single use of the macros, you won't have
> addressed my point.  No one will ever read "DAYS_PER_YEAR" in the midst
> of some code and not stop to wonder "hmm, is that 365, or 365.25, or
> 365.2425"?  And in most places where this might be used, that's not
> an ignorable issue.  I think it is actually better to write out the
> literal number, because then you can see right away what is happening.
> 
> In short, I don't think this is an improvement.

The problem is that 24 or 30 or 60 doesn't really say what it is, while
the macros are self-documenting.  The 30 is aparticular problem because
I am like, hey, what does that 30 mean, then I have to think about it. 
What we can do is to rename them to AVG_* macros so it is clear it is
approximate.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-committers by date

Next:From: Tom LaneDate: 2005-07-21 04:57:05
Subject: Re: pgsql: Add time/date macros for code clarity: #define DAYS_PER_YEAR
Previous:From: Tom LaneDate: 2005-07-21 04:52:37
Subject: Re: pgsql: Add time/date macros for code clarity: #define DAYS_PER_YEAR

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group