> > On further contemplation, it occurs to me that if we make the switch > to "key values are stored per normal rules", then even if there is an > index with pass-by-value keys out there someplace, it would only break > on big-endian architectures. On little-endian, the extra space > occupied by the Datum format would just seem to be padding space. > So this probably means that the theoretical compatibility hazard is > small enough to be negligible, and we should go with my option #2 > (i.e., we need to replace SGLTDATUM with normal attribute-fetch logic). > > regards, tom lane >
I am sorry for the delay in reply. Now I've returned to the work on the patch. First of all big thanks for good pieces of advice. I especially liked the idea of not allocating a big array in a picksplit procedure and doing deform and form tuples on the fly. I found all notes mentioned are quite worth integrating into the patch, and have made the next version of a patch (with a pgindent done also). PFA v 14. I hope I understand the way to modify SGLTDATUM in the right way. If not please let me know. (The macro SGLTDATUM itself is not removed, it calls fetch_att. And I find this suitable as the address for the first tuple attribute is MAXALIGNed). Thanks again for your consideration. From now I hope to be able to work on the feature with not so big delay. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>
v14-0001-Covering-SP-GiST-index-support-for-INCLUDE-colum.patch
Description: Binary data
