Re: Set query_id for query contained in utility statement

From: Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Set query_id for query contained in utility statement
Date: 2024-08-30 07:37:03
Message-ID: CAO6_XqoXPyoChZmjaWbcKt0B8jAo_0hc4+jv-ej-ZT4vGz4WRg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 27, 2024 at 11:14 AM jian he <jian(dot)universality(at)gmail(dot)com> wrote:
> 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.

Thanks for the review. I think the parser state is mostly used for the
error callbacks and parser_errposition but I'm not 100% sure. Either
way, you're right and it probably shouldn't be in the patch. I've
modified the patch to restrict the changes to only add the necessary
query jumble and post parse hook calls.

Attachment Content-Type Size
v4-0001-Set-query_id-for-queries-contained-in-utility-sta.patch application/octet-stream 28.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2024-08-30 08:19:12 Re: ANALYZE ONLY
Previous Message Amit Langote 2024-08-30 07:32:51 Re: pgsql: Add more SQL/JSON constructor functions