From: Tom Lane <tgl@sss.pgh.pa.us>
To: zuming.jiang@inf.ethz.ch
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18292: Unexpected error: "relation "hobbies_r" does not
 exist" caused by user-defined functions
In-reply-to: <18292-55856fb8254c79d6@postgresql.org>
References: <18292-55856fb8254c79d6@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Sun, 14 Jan 2024 18:48:13 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1367516.1705287423.1@sss.pgh.pa.us>
Date: Sun, 14 Jan 2024 21:57:03 -0500
Message-ID: <1367517.1705287423@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1367517.1705287423%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> My fuzzer finds a suspicious alarm in Postgres 17devel: "ERROR:  relation
> "hobbies_r" does not exist". I report it as I think it might be an
> unexpected error.

I don't see anything unexpected here: you made a transaction-local
change in search_path that renders that table invisible.  It's not
instantly obvious how the flow of control gets to a lookup of
that table after the SET LOCAL; but evidently that's happening,
and I don't feel any urge to work out the details.

(Note that if you were expecting SET LOCAL to mean "local to this
function call", you're mistaken.  You can get that effect with a SET
clause attached to the function definition; but this is not that.)

If you want people to take this sort of report seriously, you need to
analyze the behavior yourself, not expect us to look for a bug that
probably doesn't exist.

			regards, tom lane