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 pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073