Re: defer statement logging until after parse

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: defer statement logging until after parse
Date: 2004-03-12 14:05:40
Message-ID: 200403121405.i2CE5e328193@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
>
> >The problem I see with this patch is that it doesn't print the error
> >query on a syntax error. That seems wrong.
> >
>
> It does print it. In fact the example I gave below which is from a real
> trace shows it being printed. It is just printed after the error message
> rather than before.
>
> You solution doesn't appear to address the problem of what to do if they
> ask for only DDL and one of those generates a syntax error.

My comment was that if they type "UP8ATE", and it is a syntax error, we
have no way to know if it was a DDL or not, so we don't print it.

My idea was to take log_statement, and instead of true/false, have it be
all, ddl, mod, or off/none/false(?). You keep the existing test for
log_statement where it is, but test for 'all' now, and after parse, you
check for ddl or mod, and print in those cases if the tag matches.

If they want ddl and errors, they can use log_min_error_statement to
see just statement error, and set log_statement accordingly.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2004-03-12 14:06:02 Re: [HACKERS] notice about costly ri checks (3)
Previous Message Fabien COELHO 2004-03-12 14:02:42 Re: [HACKERS] notice about costly ri checks (3)