| From: | James William Pye <pgsql(at)jwp(dot)name> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: Options for protocol level cursors | 
| Date: | 2008-06-13 01:11:25 | 
| Message-ID: | 361E10A2-8563-4907-A82B-19068BE7484D@jwp.name | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-06-13 01:11:57 | Re: default client encoding in postgresql.conf | 
| Previous Message | Robert Treat | 2008-06-13 01:00:51 | Re: default client encoding in postgresql.conf |