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