Обсуждение: 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
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
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 > -----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 >
"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