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.


> 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:

Reply via email to