Re: Query Jumbling for CALL and SET utility statements

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Query Jumbling for CALL and SET utility statements
Дата
Msg-id Yz54LU3WEYiDKS1R@paquier.xyz
обсуждение исходный текст
Ответ на Re: Query Jumbling for CALL and SET utility statements  ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>)
Ответы Re: Query Jumbling for CALL and SET utility statements  ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Add last failed connection error message to pg_stat_wal_receiver
Следующее
От: Stefan Keller
Дата:
Сообщение: Re: Lambda expressions (was Re: BUG #15471)