Bruce Momjian <br...@momjian.us> wrote: > Tom Lane wrote: >> 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 */ My first reaction that this change was about a net wash in readability for me -- in a couple places it might save me a few moments thinking about what the number was meant to represent, balanced against following the ctag back to the #define to see what number was used for things like DAYS_PER_YEAR or DAYS_PER_MONTH. Comments like the one Bruce cites above seem like they tip the scales in favor of the patch for me. Having a place to document the choice of questionable values seems like it's better than just using the questionable values "bare" all over the place. Neither omission of the justification nor repeating it seems better. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
