Thread

Re: Regression in statement locations

Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com> — 2025-05-20T07:58:04Z

On Tue, May 20, 2025 at 5:59 AM Michael Paquier <michael@paquier.xyz> wrote:
> Once I have fixed that, I've been a bit puzzled by the difference in
> output in the tests of pg_overexplain, but I think that the new output
> is actually the correct one: the queries whose plan outputs have
> changed are passed as arguments of the explain_filter() function,
> hence the location of the inner queries point at the start location of
> the inner query instead of the start of the top-level query.  Note
> that if you add a semicolon at the end of these three queries in the
> pg_overexplain tests, we finish with an end location reported.

Indeed, by dumping more details on the query string and parsed string
in pg_overexplain, the reported location does match the inner SELECT.
This seems appropriate since it is for the planned select statement.

   Executor Parameter Types: none
   Query String:  EXPLAIN (DEBUG, RANGE_TABLE, COSTS OFF) SELECT
genus, array_agg(name ORDER BY name) FROM vegetables GROUP BY genus
   Parse Location: 41 to end
   Parsed String: SELECT genus, array_agg(name ORDER BY name) FROM
vegetables GROUP BY genus

Looking at the tests, there are 2 additionals empty DO blocks:
+DO $$
+DECLARE BEGIN
+END $$;

What's the point of those? They won't be visible in the output since
we have 'toplevel IS FALSE' in the pg_stat_statements calls and they
don't fit the "DO block --- multiple inner queries with separators".

Other than that, the patch looks good.