Re: named queries and the wire protocol
От
Tom Lane
Тема
Re: named queries and the wire protocol
Дата
Msg-id
26299.1394671872@sss.pgh.pa.us
Ответ на
Re: named queries and the wire protocol (David Welton)
Список
Дерево обсуждения
named queries and the wire protocol David Welton <davidnwelton@gmail.com>
Re: named queries and the wire protocol Tom Lane <tgl@sss.pgh.pa.us>
Re: named queries and the wire protocol David Welton <davidw@dedasys.com>
Re: named queries and the wire protocol Tom Lane <tgl@sss.pgh.pa.us>
Re: named queries and the wire protocol David Welton <davidw@dedasys.com>
Re: named queries and the wire protocol Tom Lane <tgl@sss.pgh.pa.us>
David Welton writes: >> send(State, ?BIND, ["", 0, StatementName, 0, Bin1, Bin2]), >> send(State, ?EXECUTE, ["", 0, <<0:?int32>>]), >> send(State, ?CLOSE, [?PREPARED_STATEMENT, StatementName, 0]), >> send(State, ?SYNC, []), > And then the code above. So it's generating a name itself and then > destroying it once the query is done. > Perhaps this behavior is not a good idea and using the unnamed portal > would be a better idea? My point is that it *is* using the unnamed portal, AFAICS --- the ""s in the Bind and Execute commands appear to correspond to the empty strings that would select that portal. The Close on the other hand is specifying closing a prepared statement, not a portal. If you're right about the control flow around this function, then the code is generating a prepared statement, using it once, and destroying it. Which is dumb; you should instead use the unnamed-statement protocol flow, which is better optimized for that usage pattern. regards, tom lane
В списке pgsql-general по дате отправления
От: Oscar Calderon
Дата:
От: Adrian Klaver
Дата: