On Mon, 2007-02-26 at 14:52 -0500, Tom Lane wrote: > "Simon Riggs" <[EMAIL PROTECTED]> writes: > > On Mon, 2007-02-26 at 14:28 -0500, Tom Lane wrote: > >> "Simon Riggs" <[EMAIL PROTECTED]> writes: > >>> The idea of the patch is that it generates a log message which then > >>> invokes log_min_error_statement so that the SQL statement is displayed. > >>> LOG is not on the list of options there, otherwise I would use it. > >> > >> As I said, you don't understand how the logging priority control works. > >> LOG *is* the appropriate level for stuff intended to go to the server log. > > > Please look at the definition of log_min_error_statement, so you > > understand where I'm coming from. > > I *have* read the definition of log_min_error_statement. (The SGML docs > are wrong btw, as a quick look at the code shows that LOG is an accepted > value.)
OK, I should have looked passed the manual. > The real issue here is that send_message_to_server_log just does > > if (edata->elevel >= log_min_error_statement && debug_query_string != > NULL) > > to determine whether to log the statement, whereas arguably it should be > using a test like is_log_level_output --- that is, the priority ordering > for log_min_error_statement should be like log_min_messages not like > client_min_messages. We've discussed that before in another thread, but > it looks like nothing's been done yet. Hopefully not with me? Don't remember that. > In any case, if you're unhappy > with the code's choice of whether to emit the STATEMENT part of a log > message, some changes here are what's indicated, not bizarre choices of > elevel for individual messages. Well, I would have chosen LOG if I thought it was available. I'll do some more to the patch. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match