Re: Index-only scan for btree_gist turns bpchar to char

Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
> While testing the index-only scan fix, I've discovered that replacing
> the index-only scan with the index scan changes contrib/btree_gist
> output because index-only scan for btree_gist returns a string without
> padding.

Ugh, yeah. This seems to be because gbt_bpchar_compress() strips
trailing spaces (using rtrim1) before storing the value. The
idea evidently is to simplify gbt_bpchar_consistent, but it's not
acceptable if the opclass is supposed to support index-only scan.

I see two ways to fix this:

* Disallow index-only scan, by removing the fetch function for this
opclass. This'd require a module version bump, so people wouldn't
get that fix automatically.

* Change gbt_bpchar_compress to not trim spaces (it becomes just
like gbt_text_compress), and adapt gbt_bpchar_consistent to cope.
This does nothing for the problem immediately, unless you REINDEX
affected indexes --- but over time an index's entries would get
replaced with untrimmed versions.

I also wondered if we could make the fetch function reconstruct the
padding, but it doesn't seem to have access to the necessary info.

regards, tom lane