Re: Set query_id for query contained in utility statement

On Wed, Oct 23, 2024 at 11:24:11AM +0200, Anthonin Bonnefoy wrote:
> This also answers another issue I was wondering about. Should the
> child's parsestate inherit the location information when
> make_parsestate is called? That would be incorrect since this is used
> for sub-statement, pstate should reflect the size of the whole
> sub-statement. However, since this is unused, it is fine to leave the
> child parser with unset location data, which would in turn leave the
> statement's location unset in setQueryLocationAndLength.

Yeah, this argument sounds kind of right to me.

> Patch includes Micheal changes. I've left out 0002 for now to focus on 0001.

I've looked at this one again, and applied 0001.  The final result is
really nice, thanks for all your efforts here.  If this requires
tweaks in this release cycle, well, let's deal about them should they
show up.  At least the set of regression tests will show us what's
going on.

Attached is the remaining piece, for DECLARE and CTAS.  The
JumbleQuery() calls in ExecCreateTableAs() and ExplainOneUtility() for
CTAS queries are twins, showing the inner queries of CTAS
consistently.  DECLARE is covered by one call in ExplainOneUtility()
and one in PerformCursorOpen().

This should be OK as-is.  With the regression test coverage, it is
easy to see what changes.  Let's keep that around for a few more days.
--
Michael