| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Welton <davidw(at)dedasys(dot)com> |
| Cc: | Postgres general mailing list <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: named queries and the wire protocol |
| Date: | 2014-03-13 00:51:12 |
| Message-ID: | 26299.1394671872@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
David Welton <davidw(at)dedasys(dot)com> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2014-03-13 01:09:12 | Re: After paying PG Associate Cert. Exam what's the next step? |
| Previous Message | Oscar Calderon | 2014-03-12 23:13:11 | After paying PG Associate Cert. Exam what's the next step? |