From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Weird prepared stmt behavior |
Date: | 2004-05-03 20:15:10 |
Message-ID: | 87zn8p1d4h.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> I don't see how this collides with the ideas presented so far. The JDBC
> driver wants the same: they want to prepare some statements and be able
> to use them later in the session. They don't want to be paying
> attention to which prepares were committed and which ones weren't.
Oh I thought the idea was that the statement would only be available within a
transaction.
You're saying they span transactions but if the transaction rolls back then it
also rolls back the statement "creation".
Off the top of my head that doesn't seem like a problem. Though I wonder how
that meshes with other database's views on the point.
> Then prepare_cached could send a v3 Prepare and assume the statement
> will be available for the rest of the session.
Incidentally I tried to find documentation on the v3 binary prepare/execute
protocol and failed. I think I ended up looking at libpq calls which is too
high level to understand what the protocol is and isn't capable of. I have
some ideas of what the next step could be.
Where should I be looking? Source code would be fine if the wire protocol
isn't in the documentation.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2004-05-03 20:29:13 | Re: Weird prepared stmt behavior |
Previous Message | Andrew Dunstan | 2004-05-03 20:11:44 | Re: mingw configure failure workaround |