Re: Local partitioned indexes and pageinspect
От | Michael Paquier |
---|---|
Тема | Re: Local partitioned indexes and pageinspect |
Дата | |
Msg-id | 20180502020533.GA2114@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Local partitioned indexes and pageinspect (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [SPAM] Re: Local partitioned indexes and pageinspect
|
Список | pgsql-hackers |
On Tue, May 01, 2018 at 12:30:44PM -0400, Robert Haas wrote: > That's probably going to cause some translation problems. The form of > "a" that you need will vary: "a" vs. "an" in English, "un" vs. "una" > in Spanish, etc. And it wouldn't be surprising if there are problems > in some languages even if you make it "This relation is %s". There's > a reason why the documentation advises against building up > translatable strings from constituent parts. If we go this route, > it's probably best to separately translate "This relation is a > table.", "This relation is an index.", etc. Yeah, I get the feeling that this is not going to be much consistent-proof either, so while I have not been able to come up with a better idea, let's not go through this route. > However, backing up a minute, I don't think "relation \"%s\" is not a > btree index" is such a terrible message. These modules are intended > to be intended by people who Know What They Are Doing. If we do want > to change the message, I submit that the only thing that makes it a > little unclear is that a user might fail to realize that a partitioned > index is not an index. But that could be fixed just by adding a > separate message for that one case (index \"%s\" is partitioned) and > sticking with the existing message for other cases. I have been chewing on that, and I come to agree that there is perhaps little point to complicate the code as long as a failure is properly reported to the user. I propose hence the attached, which adds test cases in the contrib module set for partitioned indexes (amcheck also lacked tests for partition tables and indexes), and fixes a set of code paths to be consistent with the presence of this new relkind. Visibly I have found a bug in git, format-patch reports the following line in the stats: .../pg_visibility/expected/pg_visibility.out | 13 ++++++++++++- But the patch contents are actually correct... -- Michael
Вложения
В списке pgsql-hackers по дате отправления: