On Tue, Jan 28, 2014 at 7:53 AM, Andreas Lubensky wrote:
> That is an interesting approach. However, I see the problem that the
> functions would have to be removed when no longer needed. If that fails
> (broken connection etc.), they would be orphaned.
> Prepared statements are bound to the conne
That is an interesting approach. However, I see the problem that the
functions would have to be removed when no longer needed. If that fails
(broken connection etc.), they would be orphaned.
Prepared statements are bound to the connection, so when the connection
is closed they are gone.
On Thu, 20
On Thu, Jan 23, 2014 at 8:31 AM, Andreas Lubensky wrote:
> Hello,
> When implementing a database backend with libpq I realized that it seems
> to be impossible to declare a cursor on a prepared statement. Is this
> correct? What is the reason for this limitation?
I can't think of any but it can b
Sorry, answered wrong posting.
On Thu, Jan 23, 2014 at 6:31 AM, Andreas Lubensky wrote:
> Hello,
> When implementing a database backend with libpq I realized that it seems
> to be impossible to declare a cursor on a prepared statement. Is this
> correct? What is the reason for this limitation?
>
pgpool-II may do what you want.
On Thu, Jan 23, 2014 at 6:31 AM, Andreas Lubensky wrote:
> Hello,
> When implementing a database backend with libpq I realized that it seems
> to be impossible to declare a cursor on a prepared statement. Is this
> correct? What is the reason for this limitation?
Hello,
When implementing a database backend with libpq I realized that it seems
to be impossible to declare a cursor on a prepared statement. Is this
correct? What is the reason for this limitation?
--
with best regards,
Andreas Lubensky
--
Sent via pgsql-general mailing list (pgsql-general@
