BUG #18150: The results returned by index only scan using gist index of bpchar and seqscan have difference.

The following bug has been logged on the website:

Bug reference: 18150
Logged by: ocean li
Email address: ocean_li_996(at)163(dot)com
PostgreSQL version: 11.9
Operating system: centos7 5.10.84 x86_64
Description:

When testing consistency between index (only) scan and seqscan, I found that
the results returned by index only scan using gist index of bpchar and
seqscan have difference.
A case given below can reproduce the scene:

-- preparation
* create extension btree_gist;
* create table t1(f_char char(32));
* create index on t1 using gist (f_char);
* insert into t1 select i from generate_series(1,10000)i;

-- test
* set enable_bitmapscan to off;
* explain analyze select * from t1 where f_char = '1';
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------
Index Only Scan using t1_f_char_idx on t1 (cost=0.15..80.51 rows=21
width=132) (actual time=0.424..0.426 rows=1 loops=1)
Index Cond: (f_char = '1'::bpchar)
Heap Fetches: 1
Planning Time: 0.102 ms
Execution Time: 0.477 ms
(5 rows)

* select * from t1 where f_char = '1';
f_char
--------
1
(1 row)

* set enable_indexscan to off;
* set enable_indexonlyscan to off;
* explain analyze select * from t1 where f_char = '1';
QUERY PLAN
-----------------------------------------------------------------------------------------------
Seq Scan on t1 (cost=0.00..209.00 rows=1 width=33) (actual
time=0.016..2.336 rows=1 loops=1)
Filter: (f_char = '1'::bpchar)
Rows Removed by Filter: 9999
Planning Time: 0.076 ms
Execution Time: 2.367 ms
(5 rows)

* select * from t1 where f_char = '1';
f_char
----------------------------------
1
(1 row)

Obviously, the last paddings of index only scan return are cut. But the last
paddings of seqscan return are not cut. Actually, the difference exists in
gist index leaf key and table metadata. And I think it is caused by the
behavior of *gbt_bpchar_compress* function. Related code are:
* ...
* if (entry->leafkey)
* {
*
* Datum d = DirectFunctionCall1(rtrim1, entry->key);
* ...

I don't know whether the scene is a bug or an expected behavior. In my
opinion, it may be a bug. So it reported here.

Best regards!