Re: SP-GiST confusion: indexed column's type vs. index column type
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Pavel Borisov <pashkin.elfe@gmail.com>
Date: 2021-04-03T17:16:27Z
Lists: pgsql-hackers
I wrote: > I still want to make an opclass in which those types are different, > if only for testing purposes, but I'm having a hard time coming up > with a plan that's not totally lame. Best idea I can think of is > to wrap the input in a bytea, which just begs the question "why > would you do that?". Anybody have a less lame thought? I thought of a plan that's at least simple to code: make an opclass that takes "name" but does all the internal storage as "text". Then all the code can be stolen from spgtextproc.c with very minor changes. I'd been too fixated on finding an example in which attType and leafType differ as to pass-by-ref vs pass-by-value, but actually a test case with positive typlen vs. varlena typlen will do just as well for finding wrong-type references. And, having coded that up, my first test result is regression=# create extension spgist_name_ops ; ERROR: storage type cannot be different from data type for access method "spgist" evidently because SPGiST doesn't set amroutine->amstorage. That's silly on its face because we have built-in opclasses in which those types are different, but it probably helps explain why there are no field reports of trouble with these bugs ... regards, tom lane
Commits
-
Fix more confusion in SP-GiST.
- fd91fed3e802 13.3 landed
- dfc843d46568 14.0 landed
- 48b319e87636 12.7 landed
-
Fix confusion in SP-GiST between attribute type and leaf storage type.
- ac9099fc1dd4 14.0 landed
-
Rethink handling of pass-by-value leaf datums in SP-GiST.
- 1ebdec8c0329 14.0 cited