On Wed, Aug 2, 2017 at 10:28 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> I've thought about this kind of thing, too. But the thing is that >> most of these macros you're proposing to introduce only get used in >> one place. > > I think the value would be in having a centralized checklist of > things-to-fix-when-adding-a-new-relkind.
right. > There's more than one way > to reach that goal, though. I wonder whether the task should be defined > more like "grep for 'RELKIND_' and fix every place you find that". That way one has to scan all code and change many files. Having them centrally at one place reduces that pain. > If there are places to touch that fail to mention that string, fix > them, using comments if nothing else. I didn't get this. > (But see fe797b4a6 and > followon commits for other solutions.) That and the follow-on commits replace hard-coded relkind values by corresponding macro. Though that work it itself is important, I do not see how that helps to find all the places where the new relkind added needs to be checked. > >> I think this might cause some problems for translators. > > Yeah, the error messages that list a bunch of different relkinds in text > form are going to be a hassle no matter what. Most of the ways you might > think of to change that will violate our translatability rules. > Ok. I agree with that. May be for now, we shouldn't touch the error messages at all. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers