Portal destination issue: binary vs normal cursors

Jan,

I discovered yesterday that DECLARE BINARY CURSOR was broken in CVS tip:
when you do a FETCH from a binary cursor, you get back ASCII data.

The problem seems to have been induced by your patch for SPI cursor
support, specifically commands/command.c version 1.128: what had beenif (dest == None)    override portal's destination
withrequested dest
 
becameif (dest != queryDesc->dest)    override portal's destination with requested dest

Now a FETCH always passes the standard output destination, normally
Remote, and so this breaks binary cursors which have dest =
RemoteInternal and need to stick to that.

I changed the code to look like this:
   /*    * If the requested destination is not the same as the query's    * original destination, make a temporary
QueryDescwith the proper    * destination.  This supports MOVE, for example, which will pass in    * dest = None.    *
 * EXCEPTION: if the query's original dest is RemoteInternal (ie, it's    * a binary cursor) and the request is Remote,
wedo NOT override the    * original dest.  This is necessary since a FETCH command will pass    * dest = Remote, not
knowingwhether the cursor is binary or not.    */   if (dest != queryDesc->dest &&       !(queryDesc->dest ==
RemoteInternal&& dest == Remote))   {... override
 

This makes binary cursors work again, and it didn't break the regression
tests, but I thought you should take a look at it.  I don't know what
aspect of SPI cursors led you to make the original change, so maybe this
version isn't right for SPI cursors.
        regards, tom lane