From: | Tom Lane <tgl(at)sss(dot)pgh(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 15:51:19 |
Message-ID: | 9621.1079106679@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> Has any of this discussion taken into account the fact that a
>> querystring may contain multiple commands?
> What does the parser do if one of the statements has an error and the
> others are OK?
The whole thing is rejected. This is just an instance of the general
rule that processing of the entire querystring is abandoned at the first
error.
The current definition of log_statement has no problem because we print
the whole string, once, before parsing starts. If you put a printout
into the per-parse-tree loop then I think you are going to get multiple
printouts of the same string. You could add some state to prevent more
than one printout per querystring, but even then you'll get complaints
"I asked for DDL only, why did it print this SELECT?". ISTM the only
way to make it "work" without obvious implementation artifacts is to
actually break down the string into individual commands, which is more
work than I think this feature is worth.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2004-03-12 16:09:28 | Re: defer statement logging until after parse |
Previous Message | Andrew Dunstan | 2004-03-12 15:31:13 | Re: defer statement logging until after parse |