Applied. Changes are: For protocol-level prepare/bind/execute:
o print user name for all o print portal name if defined for all o print query for all o reduce log_statement header to single keyword o print bind parameters as DETAIL if text mode --------------------------------------------------------------------------- Bruce Momjian wrote: > > Sorry, forgot to show sample output: > > LOG: prepare sel1: SELECT $1 + $2; > LOG: bind sel1: SELECT $1 + $2; > DETAIL: $1 = "8", $2 = "5" > LOG: execute sel1: SELECT $1 + $2; > > LOG: prepare sel1: SELECT 3; > LOG: bind sel1: SELECT 3; > LOG: execute sel1: SELECT 3; > > > --------------------------------------------------------------------------- > > Bruce Momjian wrote: > > Bruce Momjian wrote: > > > Tom Lane wrote: > > > > Oliver Jowett <[EMAIL PROTECTED]> writes: > > > > > A 50-parameter query could be .. interesting .. > > > > > > > > > I realize that you need this level of output to reflect what is > > > > > happening at the protocol level, but seeing all the protocol detail > > > > > is > > > > > not really what you expect when you turn on basic statement logging, > > > > > is it? > > > > > > > > Well, we've certainly been beat up often enough about the lack of > > > > logging bind parameter values --- I don't think there's any question > > > > about the importance of printing them. I agree that the proposed format > > > > is much too verbose though. In particular, a separate LOG message per > > > > parameter is NOT what I had in mind; I want them in DETAIL lines of the > > > > bind log message. (This'd perhaps also address Oliver's issue, since > > > > if you didn't want to see the values you could turn down > > > > log_error_verbosity.) > > > > > > OK, I will continue in that direction. Will post a new patch. > > > > Updated patch attached. It prints the text bind parameters on a single > > detail line. I still have not seen portal names generated by libpq. > > -- > Bruce Momjian [EMAIL PROTECTED] > EnterpriseDB http://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly