Re: cursors on prepared queries
| От | Andro |
|---|---|
| Тема | Re: cursors on prepared queries |
| Дата | |
| Msg-id | da7021e0609120534i15cc0342g75274be6a8b01fbd@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: cursors on prepared queries ("Jeroen T. Vermeulen" <jtv@xs4all.nl>) |
| Ответы |
Re: cursors on prepared queries
|
| Список | 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
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
В списке pgsql-interfaces по дате отправления: