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
