Re: Query Jumbling for CALL and SET utility statements - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Query Jumbling for CALL and SET utility statements
Date
Msg-id Yz54LU3WEYiDKS1R@paquier.xyz
Whole thread Raw
In response to Re: Query Jumbling for CALL and SET utility statements  ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>)
Responses Re: Query Jumbling for CALL and SET utility statements
List pgsql-hackers
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?

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.

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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Add last failed connection error message to pg_stat_wal_receiver
Next
From: Stefan Keller
Date:
Subject: Re: Lambda expressions (was Re: BUG #15471)