I've committed this with a lot of mostly-cosmetic changes. The not-so-cosmetic bits had to do with confusion between the input data type and the leaf type, which isn't really your fault because it was there before :-(.
One note is that I dropped the added regression test script (index_including_spgist.sql) entirely, because I couldn't see that it did anything that justified a permanent expenditure of test cycles. It looks like you made that by doing s/gist/spgist/g on index_including_gist.sql, which might be all right except that that script was designed to test GiST-specific implementation concerns that aren't too relevant to SP-GiST. AFAICT, removing that script had exactly zero effect on the test coverage shown by gcov. There are certainly bits of spgist that are depressingly under-covered, but I'm afraid we need custom-designed test cases to get at them.
(wanders away wondering if the isolationtester could be used to test the concurrency-sensitive parts of spgvacuum.c ...)
regards, tom lane
Thanks a lot!
As for tests I mostly checked the storage and reconstruction of included attributes in the spgist index with radix and quadtree, with many included columns of different types and nulls among the values. But I consider it too big for regression. I attach radix test just in case. Do you consider something like this could be useful for testing and should I try to adapt something like this to make regression? Or do something like this on some database already in the regression suite?