Re: Extended Query, flush or sync ?
От
John DeSoi
Тема
Re: Extended Query, flush or sync ?
Дата
Msg-id
03F6E9C9-59AF-4F9B-837A-822C224DCD22@pgedit.com
Ответ на
Re: Extended Query, flush or sync ? (Raimon Fernandez)
Список
Дерево обсуждения
Re: DataRow Null values Frontend/Backend Protocol TCP/IP Raimon Fernandez <coder@montx.com>
Re: DataRow Null values Frontend/Backend Protocol TCP/IP Craig Ringer <craig@postnewspapers.com.au>
Re: DataRow Null values Frontend/Backend Protocol TCP/IP Raimon Fernandez <coder@montx.com>
Re: DataRow Null values Frontend/Backend Protocol TCP/IP Alban Hertroys <dalroi@solfertje.student.utwente.nl>
Re: DataRow Null values Frontend/Backend Protocol TCP/IP Alban Hertroys <dalroi@solfertje.student.utwente.nl>
Hi Raimon, On Dec 20, 2009, at 2:11 PM, Raimon Fernandez wrote: > > I'm not seeing my e-mails on the PostgreSQL General List ... > > ?????? Yes, my last message did not make it to the list yesterday (you obviously received it). I double checked and it was cc to the list. > I can pack all of them and send them at the same time, except de Parse, that will go at the connection beggining in my case. I have two routines, prepare and exec_prepare. To prepare a named statement for multiple uses, I use prepare (parse, describe, sync). exec_prepare can take a statement from prepare OR you can pass it the unparsed SQL instead (along with the parameters). In the second case it performs the parse first with the unnamed prepared statement (empty string) and then executes it. This is nice because if you don't need multiple executions, you can build and execute with a single network write and read. You get the safety of parameterized execution and you don't have a prepared statement to dispose of in another operation. John DeSoi, Ph.D.
В списке pgsql-general по дате отправления