Date: Tue, 14 Oct 2025 09:01:00 +0900 (JST)
Message-Id: <20251014.090100.1456332709714986500.ishii@postgresql.org>
To: alvherre@kurilemu.de
Cc: li.evan.chao@gmail.com, tgl@sss.pgh.pa.us, pramsey@cleverelephant.ca,
 ojford@gmail.com, peter@eisentraut.org, krasiyan@gmail.com,
 vik@postgresfriends.org, andrew@tao11.riddles.org.uk, david@fetter.org,
 pgsql-hackers@lists.postgresql.org
Subject: Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options
From: Tatsuo Ishii <ishii@postgresql.org>
In-Reply-To: <202510131113.mvosyuj5dbsp@alvherre.pgsql>
References: <20251013.143941.1447453701514209859.ishii@postgresql.org>
	<202510131113.mvosyuj5dbsp@alvherre.pgsql>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20251014.090100.1456332709714986500.ishii%40postgresql.org>
Precedence: bulk

> Hmm, this change made me realize that all or almost all the calls to
> get_func_name() would crash if it were to return a NULL value.  I found
> no caller that checks the return value for nullness.  I wonder why do we
> allow it to return NULL at all ... it might be better to just
> elog(ERROR) if the cache entry is not found.  

I agree it's better but what about user defined functions? Some of
them might already check the return value to emit their own error
messages, I don't know. If so, modifying get_func_name() could break
them. Maybe invent something like get_func_name_with_error(calling
elog(ERROR)) and gradually update our code?

Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp