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 05:13:51
Message-ID: 200507210513.j6L5DqL06813@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >> 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.
>
> Except that they're NOT.
>
> Anyone who is reading datetime code will be entirely familiar with the
> Gregorian calendar (and if they aren't, the macro names you propose are
> not going to help them). You cannot honestly sit there and say that
> "365" or "24" isn't going to convey anything to anyone who could
> usefully read the code in the first place.
>
> > What we can do is to rename them to AVG_* macros so it is clear it is
> > approximate.
>
> But still not clear which approximation is being used. And in most
> places where this might be used, that matters.

Well, if you want to see the approximation, look at the macro value. At
least with AVG we are documenting it is an approximation, and are doing
it consistently.

--
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

Browse pgsql-committers by date

  From Date Subject
Next Message Bruce Momjian 2005-07-21 05:18:26 pgsql: Fix integer timestamp build for macro changes.
Previous Message Bruce Momjian 2005-07-21 05:11:59 Re: pgsql: Add time/date macros for code clarity: #define