Re: BUG: pg_stat_statements query normalization issues with combined queries

> Yes. I'll try to put together a patch and submit it to the next CF.

Here it is. I'll add this to the next CF.

This patch fixes the handling of compound/combined queries by
pg_stat_statements (i.e. several queries sent together, eg with psql:
"SELECT 1 \; SELECT 2;").

This bug was found in passing while investigating a strange performance
issue I had with compound statements.

Collect query location information in parser:

* create a ParseNode for statements with location information fields
(qlocation & qlength).

* add these fields to all parsed statements (*Stmt), Query and PlannedStmt.

* statements location is filled in:

- the lexer keep track of the last ';' encountered.

- the information is used by the parser to compute the query length,
which depends on whether the query ended on ';' or on the input end.

- the query location is propagated to Query and PlannedStmt when built.

Fix pg_stat_statement:

* the information is used by pg_stat_statement so as to extract the relevant part
of the query string, including some trimming.

* pg_stat_statement validation is greatly extended so as to test options
and exercise various cases, including compound statements.

note 1: two non-statements tags (use for alter table commands) have been
moved so that all statements tags are contiguous and easy to check.

note 2: the impact on the lexer & parser is quite minimal with this
approach, about 30 LOC, most of which in one function. The largest changes
are in the node header to add location fields.

note 3: the query length excludes the final separator, so that
;-terminated and end of input terminated queries show the same.

note 4: the added test suggests that when tracking "all", queries in SQL
user functions are not tracked, this might be a bug.

--
Fabien.