Re: Query Jumbling for CALL and SET utility statements

From: "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Jeremy Schneider <schnjere(at)amazon(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>
Subject: Re: Query Jumbling for CALL and SET utility statements
Date: 2022-10-06 08:43:57
Message-ID: 66be1104-164f-dcb8-6c43-f03a68a139a7@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 10/6/22 8:39 AM, Michael Paquier wrote:
> On Mon, Sep 19, 2022 at 08:29:22AM +0200, Drouvot, Bertrand wrote:
>> Please find attached v6 taking care of the remarks mentioned above.
>> + case T_VariableSetStmt:
>> + {
>> + VariableSetStmt *stmt = (VariableSetStmt *) node;
>> +
>> + /* stmt->name is NULL for RESET ALL */
>> + if (stmt->name)
>> + {
>> + APP_JUMB(stmt->kind);
>> + APP_JUMB_STRING(stmt->name);
>> + JumbleExpr(jstate, (Node *) stmt->args);
>> + }
>> + }
>> + break;
>
> Hmm. If VariableSetStmt->is_local is not added to the jumble, then
> aren't "SET foo = $1" and "SET LOCAL foo = $1" counted as the same
> query?
>

Good catch, thanks!
While at it let's also jumble "SET SESSION foo =". For this one, we
would need to record another bool in VariableSetStmt: I'll create a
dedicated patch for that.

> I am not seeing SAVEPOINT, RELEASE, ROLLBACK .. TO SAVEPOINT
> mentioned on this thread. Would these be worth considering in what
> gets compiled? That would cover the remaining bits of
> TransactionStmt. The ODBC driver abuses of savepoints, for example,
> so this could be useful for monitoring purposes in such cases.

Agree. I'll look at those too.

>
> As of the code stands, it could be cleaner to check
> IsJumbleUtilityAllowed() in compute_utility_query_id(), falling back
> to a default in JumbleQuery(). Not that what your patch does is
> incorrect, of course.

Will look at it.

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2022-10-06 09:30:52 Re: [PoC] Improve dead tuple storage for lazy vacuum
Previous Message Drouvot, Bertrand 2022-10-06 08:36:01 Re: Query Jumbling for CALL and SET utility statements