There appears to be a problem with how this affects current logging
behavior.
I'm using
pgbench -M extended -S -T 10 bench
to test the extended protocol.
Unpatched, with log_statement=all, you get something like
LOG: execute <unnamed>: SELECT abalance FROM pgbench_accounts WHERE aid
= $1;
DETAIL: parameters: $1 = '30223'
With your patch, with log_statement=all and log_parameters=on, you get
the same, but with log_statement=all and log_parameters=off you get
LOG: execute <unnamed>: SELECT abalance FROM pgbench_accounts WHERE aid
= $1;
DETAIL: parameters: $1 = UNKNOWN TYPE
We should probably keep the existing parameter logging working as before.
This also raises the question of the new parameter name. Parameters are
already logged. So the name should perhaps be more like
log_parameters_on_error.
Some API notes on your patch: I think you can change
get_portal_bind_parameters() to take a ParamListInfo, since you're not
doing anything with the Portal other than grab the parameters. And that
would allow you to keep the signature of errdetail_params() unchanged.
I did some performance tests using the commands shown above and didn't
find any problems. Obviously the default pgbench stuff isn't very
parameter-intensive. Do you have tests with more and larger parameter
values?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services