Re: Options for protocol level cursors
От | James William Pye |
---|---|
Тема | Re: Options for protocol level cursors |
Дата | |
Msg-id | 361E10A2-8563-4907-A82B-19068BE7484D@jwp.name обсуждение исходный текст |
Ответ на | Re: Options for protocol level cursors (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Options for protocol level cursors
|
Список | pgsql-hackers |
On Jun 12, 2008, at 4:45 PM, Tom Lane wrote: > Huh? I don't see why... you might have such a limitation in a > particular driver, but not in the protocol. Oh? I know when you bind a prepared statement you have the ability state the formats of each column, but I'm not aware of the protocol's capacity to reconfigure the formats of an already existing cursor; ie, a DECLARE'd cursor. I know you can use the Describe message to learn about the cursor's column types and formats.... Got a link to the part of the protocol docs describing this feature? >> Also, the latter has other problems wrt statement parameters. I guess >> you >> could prepare(protocol level) the DECLARE, but that seems like a >> gross >> workaround as it defeats the purpose of prepared statements by >> forcing >> you >> to create a new statement for each cursor that you plan to open. > > Well, using a query for a cursor is grounds for replanning anyway, > because you might want a fast-start plan in such a case. And it's > *definitely* grounds for replanning if you are asking for SCROLL > capability --- the plan stored for a regular prepared statement > very likely can't support that. Ah, that is good to know. Thanks.
В списке pgsql-hackers по дате отправления: