David Welton <davidnwelton@gmail.com> writes:
> Specifically, I'm wondering how this code behaves in the case that the
> Execute runs into trouble:
> https://github.com/epgsql/epgsql/blob/0e84176be4b54fb712d1cc227a2b91c24b7a66ab/src/pgsql_sock.erl#L199
I guess you mean this:
command({equery, Statement, Parameters}, State) ->
#statement{name = StatementName, columns = Columns} = Statement,
Bin1 = pgsql_wire:encode_parameters(Parameters),
Bin2 = pgsql_wire:encode_formats(Columns),
send(State, ?BIND, ["", 0, StatementName, 0, Bin1, Bin2]),
send(State, ?EXECUTE, ["", 0, <<0:?int32>>]),
send(State, ?CLOSE, [?PREPARED_STATEMENT, StatementName, 0]),
send(State, ?SYNC, []),
{noreply, State};
Bearing in mind that I don't know Erlang, so I'm just assuming that these
commands work as they're apparently intended to ...
> Does the Close still clean things up properly?
If either the Bind or the Execute fails, the server will discard messages
till Sync, so the Close is not executed. But I'm not sure why you'd want
this subroutine to destroy the prepared statement? Which is what this
code appears to be doing. A Close on the unnamed portal created by the
Bind would make sense there. It's not really necessary, since the unnamed
portal is recycled anyway when next used, but it's good style. (Because
it's not necessary, there's no need to worry about it not being executed
if the Execute fails.)
If you were using a named portal for execution, error recovery would
become a more interesting topic, but with the unnamed portal you don't
need to sweat it much.
regards, tom lane
