Added to TODO:
o Allow pooled connections to query prepared queries
o Allow pooled connections to close all open WITH HOLD cursors
---
Neil Conway wrote:
> On Fri, Aug 08, 2003 at 04:00:22PM -0400, Tom Lane
TODO item?
---
Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > On Fri, 2003-08-08 at 16:00, Tom Lane wrote:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >>> Seems we have a problem with pooled connections an
> Hm. Good thought. Maybe the same is true of held cursors.
>
> It would be a simple addition at either the protocol or SQL level to
> list the names of existing prepared statements and portals. Probably
> too late for 7.4 though.
Yup.. spot these two up on the TODO list.
signature.asc
Descr
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Seems we have a problem with pooled connections and WITH HOLD cursors.
> > We have code to reset transaction state and variables via RESET ALL, but
> > how do we remove
On Fri, 2003-08-08 at 16:00, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Seems we have a problem with pooled connections and WITH HOLD cursors.
> > We have code to reset transaction state and variables via RESET ALL, but
> > how do we remove WITH HOLD cursors when we pass a conn
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Seems we have a problem with pooled connections and WITH HOLD cursors.
> We have code to reset transaction state and variables via RESET ALL, but
> how do we remove WITH HOLD cursors when we pass a connection to a new
> client?
Prepared statements would
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
> Seems we have a problem with pooled connections and WITH HOLD cursors.
> We have code to reset transaction state and variables via RESET ALL, but
> how do we remove WITH HOLD cursors when we p
Bruce Momjian <[EMAIL PROTECTED]> writes:
> TODO item?
Yeah. I'm leaning towards the idea that a protocol addition is what to
do.
>> Hm. Good thought. Maybe the same is true of held cursors.
>>
>> It would be a simple addition at either the protocol or SQL level to
>> list the names of existi
On Fri, Aug 08, 2003 at 04:00:22PM -0400, Tom Lane wrote:
> Prepared statements would be just as much of a problem. I think the
> correct answer is simply "don't use those features in a pooled
> environment".
Well, unless you're prepared to manually manage these resources
yourself (i.e. DEALLOCAT
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > What would be interesting is a CREATE OR REPLACE functionality for
> > prepared cursors, where you could ask for it to be prepared, but if it
> > already existed, it would do nothing, or something like that.
>
> I don't think you coul
Rod Taylor <[EMAIL PROTECTED]> writes:
> On Fri, 2003-08-08 at 16:00, Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> Seems we have a problem with pooled connections and WITH HOLD cursors.
>>> We have code to reset transaction state and variables via RESET ALL, but
>>> how do we re
Whew. To the best of my knowledge, JDBC at least doesn't provide any
API by which one could discover such a thing anyway, (although I guess a
given driver could implement some sort of statement cache with a name
lookup mechanism). I guess if it were part of the standards JDBC API
we'd have hea
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Seems we have a problem with pooled connections and WITH HOLD cursors.
We have code to reset transaction state and variables via RESET ALL, but
how do we remove WITH HOLD cursors when we pass a connection to a new
client?
Prepared s
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Seems we have a problem with pooled connections and WITH HOLD cursors.
> > We have code to reset transaction state and variables via RESET ALL, but
> > how do we remove WITH HOLD cursors when we pass a connection to a new
> > client?
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What would be interesting is a CREATE OR REPLACE functionality for
> prepared cursors, where you could ask for it to be prepared, but if it
> already existed, it would do nothing, or something like that.
I don't think you could call that CREATE OR REPLAC
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > TODO item?
>
> Yeah. I'm leaning towards the idea that a protocol addition is what to
> do.
I put this under "Clients":
* Allow clients to query WITH HOLD cursors and prepared statements
I am confused why a protocol change
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Prepared statements would be just as much of a problem. I think the
>> correct answer is simply "don't use those features in a pooled
>> environment".
> Ouch. Double ouch in fact. I'm using prepared statements extensively in
> my cu
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Yeah. I'm leaning towards the idea that a protocol addition is what to
>> do.
> I am confused why a protocol change would be desired.
I was thinking that you might want it at a lower level than having to
issue a SQL command to get at
18 matches
Mail list logo
