Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:How about the callback solution for the SELECT case that was copied from the original? Should I consider open-coding in copy.c what ExecutorRun() does to avoid the callback?Adding a DestReceiver type is a good solution ... although that static variable is not. Instead define a DestReceiver extension struct that can carry the CopyState pointer for you.
Done.
You could also consider putting the copy-from-view-specific state fields into DestReceiver instead of CopyState, though this is a bit asymmetric with the relation case so maybe it's not really cleaner.
Left it alone for now.
BTW, lose the tuple_to_values function --- it's an extremely bad reimplementation of heap_deform_tuple.
Done.
copy_dest_printtup also seems coded without regard for the TupleTableSlot access API (read printtup() to see what to do instead).
I am still interpreting it. Can you give me some hints besides using slot_getallattrs(slot)?
And what's the point of factoring out the heap_getnext loop as CopyRelationTo? It's not like that lets you share any more code. The inside of the loop, ie what you've called CopyValuesTo, is the sharable part.
Done. The option parsing and error checking is now common. I also changed it to use transformStmt() in analyze.c. However, both the UNION and sunselect cases give me something like this: ERROR: could not open relation 1663/16384/16723: No such file or directory What else can I do with it? Best regards, Zoltán Böszörményi
pgsql-copyselect-4.patch.gz
Description: Unix tar archive
---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
