Re: RangeTblEntry jumble omissions - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: RangeTblEntry jumble omissions
Date
Msg-id f3tktsqbykco6ywzwszhsltqigup3hs36tsrljyat4fi5ljrta@ni4xi6l7fs7e
Whole thread Raw
In response to Re: RangeTblEntry jumble omissions  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Fri, Feb 23, 2024 at 11:00:41PM +0100, Alvaro Herrera wrote:
>
> Another, similar but not quite: if you do
>
> SET search_path TO foo;
> SELECT * FROM t1;
> SET search_path TO bar;
> SELECT * FROM t1;
>
> and you have both foo.t1 and bar.t1, you'll get two identical-looking
> queries in pg_stat_statements with different jumble IDs, with no way to
> know which is which.  Not sure if the jumbling of the RTE (which
> includes the OID of the table in question) itself is to blame, or
> whether we want to store the relevant schemas with the entry somehow, or
> what.  Obviously, failing to differentiate them would not be an
> improvement.

Yeah that's also a very old known problem.  This has been raised multiple times
(on top of my head [1], [2], [3]).  At this point I'm not exactly holding my
breath.

[1]: https://www.postgresql.org/message-id/flat/8f54c609-17c6-945b-fe13-8b07c0866420%40dalibo.com
[2]: https://www.postgresql.org/message-id/flat/9baf5c06-d6ab-c688-010c-843348e3d98c%40gmail.com
[3]: https://www.postgresql.org/message-id/flat/3aa097d7-7c47-187b-5913-db8366cd4491%40gmail.com



pgsql-hackers by date:

Previous
From: Ivan Trofimov
Date:
Subject: libpq: PQfnumber overload for not null-terminated strings
Next
From: Tender Wang
Date:
Subject: "type with xxxx does not exist" when doing ExecMemoize()