| From: | "Adrian Maier" <adrian(dot)maier(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Statements with syntax errors are not logged |
| Date: | 2006-10-20 07:13:26 |
| Message-ID: | cd30ef8c0610200013m276e081cn212a1fe3986f2f8c@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 10/19/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > When setting log_statement = 'all', statements that fail parsing are not
> > logged.
> > Is that intentional?
>
> The 'mod' and 'ddl' settings obviously can't be handled until after
> basic parsing. We could create a completely separate code path for
> 'all' but I'm not sure I see the point.
Hello,
Sometimes it can be very useful to be able to see even the incorrect
commands: for example when the incorrect query is generated by an
application or library that you haven't written yourself .
A few days ago I was experimenting with Lazarus (an object-pascal
based IDE similar to Delphi) and I was getting some unexpected syntax
errors. In order to debug the problem i had to hack the sources of the
postgres unit and add some writeln's right before the PQexec calls .
It would have been much more convenient to see the bad queries in
the logs ...
--
Adrian Maier
| From | Date | Subject | |
|---|---|---|---|
| Next Message | NikhilS | 2006-10-20 07:49:01 | Microseconds granularity SIGALRM interrupt support |
| Previous Message | Jeremy Drake | 2006-10-20 06:37:16 | row-wise comparison question/issue |