Re: Set query_id for query contained in utility statement - Mailing list pgsql-hackers

From jian he
Subject Re: Set query_id for query contained in utility statement
Date
Msg-id CACJufxGo5dMZ+=g3F_xje_C-kKe8RH_vjsTaPdZNv8P===jAvw@mail.gmail.com
Whole thread Raw
In response to Set query_id for query contained in utility statement  (Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>)
List pgsql-hackers
On Mon, Aug 26, 2024 at 4:55 PM Anthonin Bonnefoy
<anthonin.bonnefoy@datadoghq.com> wrote:
>

  /* Evaluate parameters, if any */
  if (entry->plansource->num_params)
  {
- ParseState *pstate;
-
- pstate = make_parsestate(NULL);
- pstate->p_sourcetext = queryString;

you deleted the above these lines, but passed (ParseState *pstate) in
ExplainExecuteQuery
how do you make sure ExplainExecuteQuery passed (ParseState *pstate)
the p_next_resno is 1 and p_resolve_unknowns is true.
maybe we can add some Asserts like in ExplainExecuteQuery

    /* Evaluate parameters, if any */
    if (entry->plansource->num_params)
    {
        Assert(pstate->p_next_resno == 1);
        Assert(pstate->p_resolve_unknowns == 1);
   }



also it's ok to use passed (ParseState *pstate) for
{
        estate = CreateExecutorState();
        estate->es_param_list_info = params;
        paramLI = EvaluateParams(pstate, entry, execstmt->params, estate);
}
?
I really don't know.



some of the change is refactoring, maybe you can put it into a separate patch.



pgsql-hackers by date:

Previous
From: Gabriele Bartolini
Date:
Subject: Re: RFC: Additional Directory for Extensions
Next
From: Etsuro Fujita
Date:
Subject: Re: Cross-version Compatibility of postgres_fdw