Neil Conway <neilc@samurai.com> writes:
> While reviewing Joachim Wieland's patch to add a pg_cursors system view,
> I noticed that the patch assumes that debug_query_string contains the
> portion of the submitted query string that corresponds to the SQL
> statement we are currently executing. That is incorrect:
Yeah, this has annoyed me for some time. debug_query_string is really
just a quick hack and has already been stretched well past its intended
use. I don't think you get the right result for situations where the
active query has been submitted via SPI, either: debug_query_string will
show the outermost interactive command, which may have little to do with
the query that got the error.
The appropriate way to fix it IMHO is to get the lexer+grammar to
identify the statement boundary(s) in the source string and add explicit
support in the parser for saving away the appropriate strings.
This would tie nicely into something else I'd like to do someday, which
is improve parse-analysis error reports by being able to finger the
offending construct more precisely. When we report something like an
unknown variable name in a huge query, it really sucks that we can't
give an error cursor the way simple lexer or grammar errors do. To
fix that, tokens generated by the lexer/grammar need to carry along
text positions ... and the position of the semicolon token is just what
we'd need to create proper statement strings, too.
regards, tom lane