| 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-12 23:40:27 | 
| Message-ID: | 5C636ADD-0006-41E1-9801-8AAAA0651F47@jwp.name | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Jun 12, 2008, at 3:59 PM, Tom Lane wrote:
> Sure, but if you're willing to use a SQL-level operation on the portal
> then you could perfectly well declare the cursor at SQL level too.
Indeed, but like I said in my initial e-mail::
    I know you can use DECLARE, but I believe that this inhibits the
    driver from being able to select the transfer format for individual
    columns; it's all binary or it's all text. Also, I don't think I
    can DECLARE against a prepared statement, save restating the  
query, no?
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. Of  
course,
unless you can close the existing one before opening the next one.
[ I really do hope that I'm missing something, btw :( ]
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-06-12 23:42:04 | Re: b64_encode and decode | 
| Previous Message | Joshua D. Drake | 2008-06-12 23:35:14 | Re: How to Sponsor a Feature |