Right now this patch does not support GIN because GIN doesn't support amgettuple.
It could be made to support GIN by doing a bitmap index scan, manually fetching the next tuple (or, if it's lossy, the next one on the page), checking it against the snapshot, and then rechecking it to make sure it still matches. The API I'm looking for is essentially the same as index_getnext(), which makes the most sense for finding constraint violations. Is it possible to re-add amgettuple to GIN, and just set the cost high so it's not chosen by the planner? Or is there some reason this is fundamentally a bad idea (or won't work at all)? I know we removed it in 8.4: http://archives.postgresql.org/pgsql-hackers/2009-02/msg01123.php http://archives.postgresql.org/pgsql-hackers/2009-02/msg00532.php but the reasoning seemed mostly because: 1. GIN could not support amgettuple efficiently (lots of rechecking) 2. Normal index scans did not fit a common use case for GIN, anyway However, if my feature needs to perform this check anyway (to support GIN, that is), it seems like it could be re-added. There was also some resistance to removing it in the first place (e.g. for anti-joins), so perhaps it can be made to be efficient again during the 8.5 cycle. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers