From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Joe Conway <mail(at)joeconway(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Subject: | Re: Macros bundling RELKIND_* conditions |
Date: | 2017-08-02 16:58:19 |
Message-ID: | 12916.1501693099@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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".
If there are places to touch that fail to mention that string, fix
them, using comments if nothing else. (But see fe797b4a6 and
followon commits for other solutions.)
> 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-08-02 17:00:00 | Re: pgbench: Skipping the creating primary keys after initialization |
Previous Message | Peter Eisentraut | 2017-08-02 16:41:50 | Re: Re: [BUGS] BUG #14758: Segfault with logical replication on a function index |