Alexander Lakhin <exclus...@gmail.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
