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