On 08/02/2017 10:30 PM, Ashutosh Bapat wrote: > On Wed, Aug 2, 2017 at 8:47 PM, Robert Haas <robertmh...@gmail.com> wrote: >> 0001-RELKIND_HAS_VISIBILITY_MAP.patch - one place >> 0002-RELKIND_HAS_STORAGE.patch - one place >> 0003-RELKIND_HAS_XIDS-macro.patch - one place >> 0004-RELKIND_HAS_COMPOSITE_TYPE-macro.patch - one place >> 0005-RELKIND_CAN_HAVE_TOAST_TABLE-macro.patch - one place >> 0006-RELKIND_CAN_HAVE_COLUMN_COMMENT-macro.patch - one place >> 0007-RELKIND_CAN_HAVE_INDEX-macro.patch - two places >> 0008-RELKIND_CAN_HAVE_COLUMN_SECLABEL-macro.patch - one place >> 0009-RELKIND_CAN_HAVE_STATS-macro.patch - two places >> >> I'm totally cool with doing this where we can use the macro in more >> than one place, but otherwise I don't think it helps.
I disagree. > Can we say that any relation that has visibility map will also have > xids? If yes, what's that common property? Perhaps there are better ways to achieve the same goal (e.g. nearby comments), but I think this is the salient point. The macro names allow whoever is looking at the code to focus on the relevant properties of the relkind without having to arrive at the conclusion themselves that relkind "A" has property "B". Makes the code easier to read and understand IMHO. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
signature.asc
Description: OpenPGP digital signature
