On Mon, Oct 7, 2024 at 1:39 PM Michael Paquier <mich...@paquier.xyz> wrote:
>
> On Fri, Oct 04, 2024 at 08:16:00PM +0800, jian he wrote:
> > about v5 0001
> > select_with_parens:
> > '(' select_no_parens ')' { $$ = $2; }
> > | '(' select_with_parens ')' { $$ = $2; }
> > ;
> >
> >
> > toplevel | calls | query
> > ----------+-------+-------------------------------------------------------
> > t | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
> > t | 0 | SELECT toplevel, calls, query FROM pg_stat_statements+
> > | | ORDER BY query COLLATE "C", toplevel
> > t | 1 | explain (select $1)
> > f | 1 | select $1);
> >
> > query "select $1);" looks weird. not sure how to improve it,
> > or this should be the expected behavior?
>
> GOod point, this is confusing. The point is that having only
> stmt_location is not enough to detect where the element in the query
> you want to track is because it only points at its start location in
> the full query string. In an ideal world, what we should have is its
> start and end, pass it down to pgss_store(), and store only this
> subquery between the start and end positions in the stats entry.
> Making that right through the parser may be challenging, though.
>
turns out UPDATE/DELETE/MERGE and other utilities stmt cannot have
arbitrary parenthesis with EXPLAIN.
attached patches can solve this specific problem.
(based on v5-0001-Track-location-to-extract-relevant-part-in-nested.patch)
the main gotcha is to add location information for the statement that
is being explained.
typedef struct ExplainStmt
{
NodeTag type;
Node *query; /* the query (see comments above) */
List *options; /* list of DefElem nodes */
ParseLoc location; /* location of the statement being explained */
} ExplainStmt;
explain select 1;
explain (select 1);
explain (((select 1)));
the above 3 explained select queries will be normalized to one select query.
v5-0001-exposse_explained_stmt_location.no-cfbot
Description: Binary data
