Andrew Dunstan wrote: > Bruce Momjian wrote: > > >Andrew Dunstan wrote: > > > > > > > wow. that was nearly 3 months ago ...
Oh, I remember why I kept this email now. I am going to try to code this. > Subsequent discussion suggested we should add "syntax-errors" to the > allowed values (and I would favor making it the default). We already have log_min_error_statement. Seems that is what should be used if someone wants only syntax errors. > The problem is this - in order to make the decision about whether or not > to log, we need to have parsed the statement (unless the level is set > to "all"). My simple approach, which would mean that the entire patch > would amount to around 100 lines, maybe, plus docco, would have the (I > think) trivial side effect of reversing the order in which a logged > statement and the corresponding parse error log entry appeared. You > objected to that effect, so I stopped work on it. > > Now I can think of a couple of different approaches which would not have > this effect: > a. embed a time machine in postgres so we can make a decision based on > information we do not yet have, or > b. find some spot where we can trap the parse error log message before > it is emitted and then first log the statement. That spot is probably > somewhere in src/backend/utils/error/elog.c, but I am not quite sure where. > > I have rejected as ugly and unmaintainable monkeying with the parser > itself to produce the desired effect, and I regret that idea a is beyond > my humble abilities :-) I will start on this now. Thanks. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
