Re: Regression in statement locations - Mailing list pgsql-hackers

From Anthonin Bonnefoy
Subject Re: Regression in statement locations
Date
Msg-id CAO6_Xqr2SVquEKdppmuo+EfaEN0MrCSS6ALRd4tgC_OFjJoTrw@mail.gmail.com
Whole thread Raw
In response to Re: Regression in statement locations  (jian he <jian.universality@gmail.com>)
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: Nazir Bilal Yavuz
Date:
Subject: Re: fix: propagate M4 env variable to flex subprocess
Next
From: Tomas Vondra
Date:
Subject: Re: generic plans and "initial" pruning