Hello, > > I've modified the patch to work in such a way. Also, as ISTM the patch > > is more complicated than what the patch really does, I've simplified the > > patch. > > I've revised the patch a bit. Please find attached the patch.
Thank you, but it seems to me too simplified. You made two major functional changes. One is, you put the added code for getrelation_info() out of the block for the condition (info->relam == BTREE_AM_OID) (though amcanorder would be preferable..) Anyway the reason for the place is to guarantee 'full_ordered' index always to be orderable. I believe the relation between them are not obvious. So your patch has an oppotunity to make wrong assumption for possible indexes which is not orderable but unique. Going on your way some additional works would be needed to judge an index to be orderable or not on checking the extensibility of pathkeys. Another is, you changed pathkeys expantion to be all-or-nothing decision. While this change should simplify the code slightly, it also dismisses the oppotunity for partially-extended pathkeys. Could you let me know the reason why you did so. Any thoughts? regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
