Postgres Pro
Downloads
Home   >   mailing lists

Thread: Portal destination issue: binary vs normal cursors

Portal destination issue: binary vs normal cursors

From
Tom Lane
Date:
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

Re: Portal destination issue: binary vs normal cursors

From
Bruce Momjian
Date:
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,
Pennsylvania19026

Maintained Date Formats

From
Date:
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

RE: Portal destination issue: binary vs normal cursors

From
"Christopher Kings-Lynne"
Date:
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
>

Re: Portal destination issue: binary vs normal cursors

From
Tom Lane
Date:
"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