Note about KNNGIST limitation: no mark/restore

While working on the KNNGIST documentation I noticed that it's possible
to create queries that will try to use a KNN scan as the inside of a
mergejoin, leading to a failure because GIST hasn't got mark/restore
support. For example, in the current HEAD regression database:

regression=# set enable_seqscan TO 0;
SET
regression=# explain select * from point_tbl a, point_tbl b where (a.f1 <-> '(0,0)') = (b.f1 <-> '(0,0)') order by (a.f1 <-> '(0,0)');
QUERY PLAN
------------------------------------------------------------------------------------
Merge Join (cost=0.00..16.94 rows=7 width=32)
Merge Cond: ((a.f1 <-> '(0,0)'::point) = (b.f1 <-> '(0,0)'::point))
-> Index Scan using gpointind on point_tbl a (cost=0.00..8.37 rows=7 width=16)
Order By: (f1 <-> '(0,0)'::point)
-> Index Scan using gpointind on point_tbl b (cost=0.00..8.37 rows=7 width=16)
Order By: (f1 <-> '(0,0)'::point)
(6 rows)

regression=# select * from point_tbl a, point_tbl b where (a.f1 <-> '(0,0)') = (b.f1 <-> '(0,0)') order by (a.f1 <-> '(0,0)');
ERROR: GiST does not support mark/restore

The current planner code will not consider a KNN scan unless it
matches the query's ORDER BY, so the ORDER BY in the above example is
required to provoke the failure.

This seems like a sufficiently far-fetched example that I'm not too
concerned about it. Adding mark/restore to GiST KNN scans doesn't look
practical at all; so if we were to try to do something, it would need to
involve hacking the planner to know that this plan type doesn't work,
which seems possible but klugy.

regards, tom lane