pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedcursors on prepared queries
4+ messages / 3 participants
[nested] [flat]
* cursors on prepared queries
@ 2006-09-12 10:18 Andro <andromede@gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: Andro @ 2006-09-12 10:18 UTC (permalink / raw)
To: pgsql-interfaces
Hi,
there isn't any interface for using cursors within libpq, I'll do with a
PQexec(conn,"DECLARE..."); and fetch.
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) :
PREPARE plan_name(int) AS SELECT * FROM abc WHERE a = $1;
DECLARE cur CURSOR FOR EXECUTE(3);
doing so, I get a 'syntax error at or near "EXECUTE" at character 24'
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".
I'm using postgres-8.1.4.
Any help appreciated!
Thanks
Charles
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: cursors on prepared queries
@ 2006-09-12 10:47 Jeroen T. Vermeulen <jtv@xs4all.nl>
parent: Andro <andromede@gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: Jeroen T. Vermeulen @ 2006-09-12 10:47 UTC (permalink / raw)
To: Andro <andromede@gmail.com>; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: cursors on prepared queries
@ 2006-09-12 12:34 Andro <andromede@gmail.com>
parent: Jeroen T. Vermeulen <jtv@xs4all.nl>
0 siblings, 1 reply; 4+ messages in thread
From: Andro @ 2006-09-12 12:34 UTC (permalink / raw)
To: Jeroen T. Vermeulen <jtv@xs4all.nl>; +Cc: pgsql-interfaces
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 9/12/06, Jeroen T. Vermeulen <jtv@xs4all.nl> wrote:
>
> 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
>
>
>
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: cursors on prepared queries
@ 2006-09-12 18:12 Volkan YAZICI <yazicivo@ttnet.net.tr>
parent: Andro <andromede@gmail.com>
0 siblings, 0 replies; 4+ messages in thread
From: Volkan YAZICI @ 2006-09-12 18:12 UTC (permalink / raw)
To: Andro <andromede@gmail.com>; +Cc: Jeroen T. Vermeulen <jtv@xs4all.nl>; pgsql-interfaces
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.
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2006-09-12 18:12 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-09-12 10:18 cursors on prepared queries Andro <andromede@gmail.com>
2006-09-12 10:47 ` Jeroen T. Vermeulen <jtv@xs4all.nl>
2006-09-12 12:34 ` Andro <andromede@gmail.com>
2006-09-12 18:12 ` Volkan YAZICI <yazicivo@ttnet.net.tr>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox