Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Mon, Mar 14, 2011 at 4:22 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> >> On Sat, 2011-03-12 at 22:29 +0200, Peter Eisentraut wrote:
> >>> I think it's much clearer with the plain numbers.
>
> >> Yeh. It's not like the values 24, 12 or 60 were going to change.
>
> > I had the same thought. OTOH, even in 9.0 we have constants for
> > BITS_PER_BYTE, DAYS_PER_YEAR (365.25), MONTHS_PER_YEAR, DAYS_PER_MONTH
> > (30, as it turns out), HOURS_PER_DAY, SECS_PER_YEAR (that's a
> > constant?), SECS_PER_DAY, SECS_PER_HOUR, MINS_PER_HOUR, USECS_PER_DAY,
> > USECS_PER_HOUR, USECS_PER_MINUTE, and USECS_PER_SEC. And there's no
> > real reason to use those symbols in only some of the contexts where
> > they are relevant.
>
> Well, those existing symbols are there because Bruce put them in in
> previous iterations of this same sort of patch. And as you note,
Right.
> some of them are pretty darn questionable because the underlying
> number *isn't* as well defined as all that.
The macro does allow us to centralize comments on their imprecision,
e.g.:
/* * DAYS_PER_MONTH is very imprecise. The more accurate value is * 365.2425/12 = 30.436875, or '30 days 10:29:06'.
Rightnow we only * return an integral number of days, but someday perhaps we should * also return a 'time' value to
beused as well. ISO 8601 suggests * 30 days. */#define DAYS_PER_MONTH 30 /* assumes exactly 30 days per month
*/
> If Bruce is the only person who finds this to be a readability
> improvement, maybe we should think about backing all of those
> changes out.
Yes, it should be done consistently.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
