SPI and qCache and bug?

Hi,
query cache hacking continue ...
I just implement my (context-per-plan) query cache (qCache) to SPI. 
Changed:
     SPI_saveplan()          - save plan to qcache instead to neverunallocated TopMemoryContext.
New:
     SPI_saveplan_by_key()   - save plan to qcache under specifited hash key. This is needful if user define key
oneselfor if key must be binary (non-string) - example Jan use any struct as hash key in RI's triggers.) 
 
     SPI_execp_by_key()      - same as SPI_execp(), but as arg is hash keyonly, (again, it is needful for (example)
RI).-you not need pointer to plan, you can use key only
 
     SPI_freeplan()          - remove plan from qcache and destroy allmemory associate with plan. It is end of the
TopMemoryContextfeeding:-)
 
Comments?
 A question: I look at the current PG's SPI and (IMHO) is here a littleperformance bug. Very often is used
SPI_prepare()and SPI_saveplan()together and without any relevant code between these routines. But see:SPI_prepare() -
call2x copyObject() and copy data to procedure         context
 
- well, if you need pquery plans in this context it is OK, but SPI_saveplan() - call 2x copyObject() and copy (same)
datato        TopMemoryContext (or in future to qCache)
 
SPI_execp() - call 2x copyObject() and copy data back to current         context
- hmm, it copy twice all data, but without any efect.
IMHO is solution any SPI_prepare_and_save() and copy data only toTopMemoryContext (or to qCache), we not need data in
procedurecontext (as it copy SPI_prepare), because SPI_execp() copy it to wanted contextitself. 
 
The SPI performance will interesting if RI will in real life...       
                    Karel