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=7width=32)  Merge Cond: ((a.f1 <-> '(0,0)'::point) = (b.f1 <-> '(0,0)'::point))  ->  Index Scan using gpointind on
point_tbla  (cost=0.00..8.37 rows=7 width=16)        Order By: (f1 <-> '(0,0)'::point)  ->  Index Scan using gpointind
onpoint_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