On Wed, Aug 2, 2017 at 10:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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