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. 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. BTW, lose the tuple_to_values function --- it's an extremely bad reimplementation of heap_deform_tuple. copy_dest_printtup also seems coded without regard for the TupleTableSlot access API (read printtup() to see what to do instead). 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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly