Re: Macros for time magic values

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Cc: "Bruce Momjian" <bruce@momjian.us>, "Simon Riggs" <simon@2ndquadrant.com>, "Robert Haas" <robertmhaas@gmail.com>, "Peter Eisentraut" <peter_e@gmx.net>, "PostgreSQL-development" <pgsql-hackers@postgresql.org>
Date: 2011-03-14T16:01:36Z
Lists: pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> 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.

Another advantage of the macros is that it makes it a lot easier to grep
to see where a questionable value is being used.  Originally I'd felt
that wrapping those bogus numbers in macros was a bad idea, but the
documentation and searching advantages are enough to make me think it's
all right.

			regards, tom lane