Re: query_id: jumble names of temp tables for better pg_stat_statement UX

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: query_id: jumble names of temp tables for better pg_stat_statement UX
Дата
Msg-id Z9n_K2YGbadpzD_s@paquier.xyz
обсуждение исходный текст
Ответ на query_id: jumble names of temp tables for better pg_stat_statement UX  (Christoph Berg <myon@debian.org>)
Ответы Re: query_id: jumble names of temp tables for better pg_stat_statement UX
Список pgsql-hackers
On Tue, Mar 18, 2025 at 05:51:54PM +0100, Christoph Berg wrote:
> I had thought about it, but figured that integers and strings are
> already separate namespaces, so hashing them shouldn't have any
> conflicts. But it's more clear to do that, so added in the new
> version:
>
>        AppendJumble(jstate, (const unsigned char *)"pg_temp", sizeof("pg_temp"));
>        AppendJumble(jstate, (const unsigned char *)rel_name, strlen(rel_name));

Yes, I know that it's not a big deal, but it could be confusing if
somebody makes an argument about jumbling more object names for
relations.  The problem is not only limited to relations, though, as
there are other object types that can use a temp namespace like
functions, but the case of table entries should cover most of the
complaints I can imagine.

> >  typedef struct RangeTblEntry
> >  {
> > -    pg_node_attr(custom_read_write)
> > +    pg_node_attr(custom_read_write, custom_query_jumble)
> >
> > This structure still includes some query_jumble_ignore, which are not
> > required once custom_query_jumble is added.
>
> I would tend to keep them for documentation purposes. (The other
> custom_query_jumble functions have a much more explicit structure so
> there it is clear which fields are supposed to be jumbled.)

Fine by me as well to keep a dependency based on the fact that the
structure is rather complicated, but I'd rather document that as well
in parsenodes.h with a slightly fatter comment.  What do you think?
--
Michael

Вложения

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