Re: Local partitioned indexes and pageinspect - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Local partitioned indexes and pageinspect
Date
Msg-id 20180502020533.GA2114@paquier.xyz
Whole thread Raw
In response to Re: Local partitioned indexes and pageinspect  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [SPAM] Re: Local partitioned indexes and pageinspect  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: stats_ext test fails with -DCATCACHE_FORCE_RELEASE
Next
From: Justin Pryzby
Date:
Subject: doc fixes: vacuum_cleanup_index_scale_factor