Thread: cursors on prepared queries

Hi,<br /><br />there isn't any interface for using cursors within libpq, I'll do with a PQexec(conn,"DECLARE..."); and
fetch.<br/>Now I'd like to know if it's possible to prepare a query (that takes forever to plan) and execute it into a
cursor,like (SQL) : <br /><br />PREPARE plan_name(int) AS SELECT * FROM abc WHERE a = $1;<br />DECLARE cur CURSOR FOR
EXECUTE(3);<br/><br />doing so, I get a 'syntax error at or near "EXECUTE" at character 24'<br /><br />Is something
wrongor is it just not supported by postgres? <br />Manual talks about read only cursors but I didn't find out
discussionsabout "anti-prepared-statement-cursors".<br /><br />I'm using postgres-8.1.4.<br /><br />Any help
appreciated!<br/><br />Thanks<br /><br />Charles<br /> 

On Tue, September 12, 2006 17:18, Andro wrote:

> PREPARE plan_name(int) AS SELECT * FROM abc WHERE a = $1;
> DECLARE cur CURSOR FOR EXECUTE(3);

(You'd probably also want to mention the name of the prepared statement
that you're executing somewhere :)

> Is something wrong or is it just not supported by postgres?
> Manual talks about read only cursors but I didn't find out discussions
> about
> "anti-prepared-statement-cursors".

Well, the documentation for DECLARE says that the query that cursor
executes must be a "SELECT command"--not that I personally know the
reasons behind it:

http://www.postgresql.org/docs/8.1/interactive/sql-declare.html


Jeroen

I just found this interesting link http://lists.initd.org/pipermail/psycopg/2005-October/003999.html
about psycopg python interface which looks like able to make the use of prepared statements within cursors.

That means the protocol handles it but not libpq, right?

What should we - libpq users - do? Keep trickin' or .. start pachin'? :)

Charles

On Sep 12 02:34, Andro wrote:
> I just found this interesting link
> http://lists.initd.org/pipermail/psycopg/2005-October/003999.html
> about psycopg python interface which looks like able to make the use of
> prepared statements within cursors.
> 
> That means the protocol handles it but not libpq, right?

No. Cursor understanding of Python DB adapters are quite different from
the cursor - we create with DECLARE - in an RDBMS. psycopg just tries to
imitate the cursor behaviour we're familiar with. OTOH, psycopg2 uses
libpq too. It's quite unfeasible to think a feature psycopg supports that
libpq does not.


Regards.