Portal destination issue: binary vs normal cursors

Can we get BINARY supported in ordinary SELECT too, while you are there?
Hard to argue why BINARY works only for 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 been
if (dest == None)
override portal's destination with requested dest
became
if (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 QueryDesc with 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, we do NOT override the
* original dest. This is necessary since a FETCH command will pass
* dest = Remote, not knowing whether 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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Good day,

In the on-line documentation, it's mentioned that there is an available
date format of the form YYDDD, where YY is the year, and DDD is the day of
the year.

The example given is '99008', which does show up correctly:

lx=# SELECT date('99008');
date
------------
1999-01-08
(1 row)

In fact, it shows up correctly up until I try to specify past
january, when above the 31st day of the year it fails.

lx=# SELECT date('99031');
date
------------
1999-01-31
(1 row)

lx=# SELECT date('99032');
ERROR: Bad date external representation '99032'

Is this format no longer maintained, or am I missing something? ;)

Regards,
Jw.
--
jlx@commandprompt.com
by way of pgsql-hackers@commandprompt.com

Does this mean there should be a regression test for binary cursors then...?

Chris

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

Does this mean there should be a regression test for binary cursors then...?

Sure, if you can think of a portable way to do it.

regards, tom lane