Re: Portal destination issue: binary vs normal cursors
От | Bruce Momjian |
---|---|
Тема | Re: Portal destination issue: binary vs normal cursors |
Дата | |
Msg-id | 200108102047.f7AKlQF02606@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Portal destination issue: binary vs normal cursors (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Maintained Date Formats
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: