From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Sami Imseih <samimseih(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, ma lz <ma100(at)hotmail(dot)com> |
Subject: | Re: query_id: jumble names of temp tables for better pg_stat_statement UX |
Date: | 2025-03-25 05:28:39 |
Message-ID: | Z-I_BybOhD0RGRuC@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Tue, Mar 25, 2025 at 01:17:22AM -0400, Tom Lane wrote:
> Julien Rouhaud <rjuju123(at)gmail(dot)com> writes:
> > On Tue, Mar 25, 2025 at 12:32:05AM -0400, Tom Lane wrote:
> >> 2. Tools that are not entitled to set the value of the GUC are forced
> >> to be prepared to cope with any setting. That can be anywhere from
> >> painful to impossible.
>
> > Didn't that ship already sailed in pg14 when we allowed generating custom
> > query_id?
>
> Up to a point, perhaps. If I'm writing some kind of tool that digests
> pg_stat_statements results, I think I'm entitled to disregard the
> possibility that somebody is using a custom query_id that behaves in
> ways I'm not expecting --- or at least, fixing my code for that is
> their problem not mine. But it's much harder to take that attitude
> for things that are built into core PG.
I see, that's fair.
From | Date | Subject | |
---|---|---|---|
Next Message | Álvaro Herrera | 2025-03-25 05:59:30 | Re: Today Page is not accessible - postgresql-15.spec |
Previous Message | Tom Lane | 2025-03-25 05:17:22 | Re: query_id: jumble names of temp tables for better pg_stat_statement UX |
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2025-03-25 05:32:12 | Re: Statistics Import and Export |
Previous Message | Tom Lane | 2025-03-25 05:17:22 | Re: query_id: jumble names of temp tables for better pg_stat_statement UX |