On 4/10/17 06:18, Ashutosh Bapat wrote: > This isn't exactly about this particular thread. But I noticed, that > after we introduced RELKIND_PARTITIONED_TABLE, we required to change a > number of conditions to include this relkind. We missed some places in > initial commits and fixed those later. I am wondering whether we > should creates macros clubbing relevant relkinds together based on the > purpose of the tests e.g. IS_RELKIND_HAS_STORAGE(). When a new relkind > is added, one can examine these macros to check whether the new > relkind fits in the given macro. If all those macros are placed > together, there is a high chance that we will not miss any place in > the initial commit itself.
I think this is worth a try. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
