Tom Lane wrote:
> Robert Haas <robertmh...@gmail.com> writes:
> > On Mon, Mar 14, 2011 at 4:22 AM, Simon Riggs <si...@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'. Right now we only
* return an integral number of days, but someday perhaps we should
* also return a 'time' value to be used 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 <br...@momjian.us> http://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
