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.