Re: RangeTblEntry jumble omissions

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RangeTblEntry jumble omissions
Date: 2024-02-25 12:48:59
Message-ID: f3tktsqbykco6ywzwszhsltqigup3hs36tsrljyat4fi5ljrta@ni4xi6l7fs7e
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tender Wang 2024-02-25 13:32:43 "type with xxxx does not exist" when doing ExecMemoize()
Previous Message Ivan Trofimov 2024-02-25 11:33:01 libpq: PQfnumber overload for not null-terminated strings