Re: Weird prepared stmt behavior
От | Alvaro Herrera |
---|---|
Тема | Re: Weird prepared stmt behavior |
Дата | |
Msg-id | 20040503195100.GF30007@dcc.uchile.cl обсуждение исходный текст |
Ответ на | Re: Weird prepared stmt behavior (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: Weird prepared stmt behavior
|
Список | pgsql-hackers |
On Mon, May 03, 2004 at 03:18:37PM -0400, Greg Stark wrote: > > Tom Lane <tgl@sss.pgh.pa.us> writes: > > > Before jumping into doing that, though, I'd want to have some > > discussions about the implications for the V3 protocol's notion of > > prepared statements. The protocol spec does not say anything that > > would suggest that prepared statements are lost on transaction rollback, > > and offhand it seems like they shouldn't be because the protocol is > > lower-level than transactions. > > Woah, that would totally defeat the purpose of prepared statements. > > The idea is that an OLTP system can prepare all the statements it will ever > need at startup time. Then simply execute them with various parameters as > needed. 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. > Using a good driver like Perl's DBI this just means using something like > prepare_cached() instead of prepare(). Then prepare_cached could send a v3 Prepare and assume the statement will be available for the rest of the session. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end." (2nd Commandment for C programmers)
В списке pgsql-hackers по дате отправления: