Andrew Dunstan wrote: > Bruce Momjian wrote: > > >Right now we have log_min_error_statement: > > > > #log_min_error_statement = panic # Values in order of increasing severity: > > # debug5, debug4, debug3, debug2, debug1, > > # info, notice, warning, error, panic(off) > > > >which does allow control of printing only statements generating errors, > >which includes syntax errors. I don't see why this functionality should > >be mixed in with log_statement. > > > >Did you want a 'syntax error' level to log_statement, that would print > >only statements with syntax errors but not other errors? That doesn't > >seem very useful to me. > > > > > > > > It wasn't my idea, but I thought it was a good one. But it would go > along with the idea of these settings as a list instead of a hierarchy, > e.g.: > > log_statement = "syntax-errors, ddl, mod" > > In fact, I liked it so much that I thought "syntax-errors" should be the > default instead of "none". > > I think I'd prefer that to having it tied to the log_min_error_statement > level. But I don't care that much.
Advertising
OK, at least we understand each other. Right now we don't have any special "syntax error" log processing. We have errors logged through log_min_error_statement, and mod/ddl through the new log_statement. I can see a use case for having mod/ddl control of logging, and error control of logging, but why would you want to see syntax error queries but not other error queries? That's why I think log_min_error_statement is sufficient. If we add syntax logging, wouldn't that conflict with log_min_error_statement logging, because those are errors too. Maybe we need to add a 'synax' mode to log_min_error_statement above error that logs only syntax errors but not others. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
