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
> 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.
The Postgres Database Company
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: