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

Fri, 10 Aug 2001 16:19:24 -0400
Tom Lane <tgl@sss.pgh.pa.us>
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

Fri, 10 Aug 2001 16:47:26 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Portal destination issue: binary vs normal cursors
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


Fri, 10 Aug 2001 14:08:54 -0700 (PDT)
<pgsql-hackers@commandprompt.com>
Maintained Date Formats
Does this mean there should be a regression test for binary cursors then...?

Chris

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Tom Lane
> Sent: Saturday, 11 August 2001 4:19 AM
> To: Jan Wieck
> Cc: pgsql-hackers@postgresql.org
> Subject: [HACKERS] 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 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
>


Mon, 13 Aug 2001 09:48:49 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
RE: Portal destination issue: binary vs normal cursors
"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

Sun, 12 Aug 2001 23:09:26 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Portal destination issue: binary vs normal cursors 