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.


  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.


  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.


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

Attachment: pgsql-copyselect-4.patch.gz
Description: Unix tar archive

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to