Some oversights in query_id calculation

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Some oversights in query_id calculation
Дата
Msg-id 20210425081119.ulyzxqz23ueh3wuj@nol
обсуждение исходный текст
Ответы Re: Some oversights in query_id calculation
Список pgsql-hackers
Hi,

While doing some sanity checks on the regression tests, I found some queries
that are semantically different but end up with identical query_id.

Two are an old issues:

- the "ONLY" in FROM [ONLY] isn't hashed
- the agglevelsup field in GROUPING isn't hashed

Another one was introduced in pg13 with the WITH TIES not being hashed.

The last one new in pg14: the "DISTINCT" in "GROUP BY [DISTINCT]" isn't hash.

I'm attaching a patch that fixes those, with regression tests to reproduce each
problem.

There are also 2 additional debatable cases on whether this is a semantic
difference or not:

- aliases aren't hashed.  That's usually not a problem, except when you use
  row_to_json(), since you'll get different keys

- the NAME in XmlExpr (eg: xmlpi(NAME foo,...)) isn't hashed, so you generate
  different elements

Вложения

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

Предыдущее
От: Yura Sokolov
Дата:
Сообщение: Re: Use simplehash.h instead of dynahash in SMgr
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: compute_query_id and pg_stat_statements