Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wNQt8-000nxc-37 for pgsql-hackers@arkaria.postgresql.org; Thu, 14 May 2026 07:53:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wNQt5-00BKaF-1d for pgsql-hackers@arkaria.postgresql.org; Thu, 14 May 2026 07:53:43 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wNQt4-00BKa5-3A for pgsql-hackers@lists.postgresql.org; Thu, 14 May 2026 07:53:43 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wNQt2-00000000Uya-0WIy for pgsql-hackers@postgresql.org; Thu, 14 May 2026 07:53:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Content-Transfer-Encoding:Content-Type: Mime-Version:References:In-Reply-To:From:Subject:Cc:To:Message-Id:Date:Sender :Reply-To:Content-ID:Content-Description; bh=YoOYecVOOuV3mrmEkkmSzs1XPS5nl9zafULLU4/azDA=; b=TtTgYDMq4aHSzM3pTsG0Ok1xf0 nQWPdQqCYHZiR724sjBmBXRr/fU/oONeG+xFzAfqgbEeQUljEwxaE/SeY6K0GNVFjT9OYVd0mRHvJ YjWEwtpAIA9nrcdNCYHVKD1eoSvlyUhbT9FVvCbnDjQL/xMRzIMx8DIhQ+Bry+X8AHSdXgkLQq6H9 Z881GxoslxYWEM6lNzxOOV3H8A0f6s13sjCzBsaXOHsgcLDd0hXuBGb4IJvl9Lo4bPn5lYlI+EhQv Bo50Xea732HtB2J4ePYJiZD8gsB9FLre2Bzqx6yENmw8Cn8SFew6qIQ5pnq/8nvfH6+E784uZDCMx UO26faHg==; Received: from [2409:11:4120:300:123e:a52d:1240:92e7] (helo=localhost) by meldrar.postgresql.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wNQsx-001Nfw-0W; Thu, 14 May 2026 07:53:39 +0000 Date: Thu, 14 May 2026 16:53:23 +0900 (JST) Message-Id: <20260514.165323.1913944269609196803.ishii@postgresql.org> To: li.evan.chao@gmail.com Cc: pgsql-hackers@postgresql.org, ojford@gmail.com Subject: Re: Should IGNORE NULLS cache nullness for volatile arguments? From: Tatsuo Ishii In-Reply-To: <42B42506-6972-4266-8422-FB73E61D9DA7@gmail.com> References: <42B42506-6972-4266-8422-FB73E61D9DA7@gmail.com> X-Mailer: Mew version 6.8 on Emacs 29.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2409:11:4120:300:123e:a52d:1240:92e7 (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Chao, Thank you for the test and patches. > Hi, > > I tested the new IGNORE NULLS support for window functions and noticed one behavior that looks strange to me. > > To avoid repeated evaluation, the current code caches whether an argument value is NULL or NOT NULL. That is fine for stable expressions, but it looks unsafe for volatile arguments. For example, an argument may be evaluated as NOT NULL when its nullness is first checked, but when the value is needed later and the argument is evaluated again, the result may become NULL. That can lead to surprising results for volatile functions. > > I do not have full confidence to call this a bug yet, but I think it is at least worth discussing. If the value of a NOT NULL argument were also cached, then I guess this behavior might be acceptable. But with the current implementation, the argument can be re-evaluated later and produce the opposite nullness result, which seems wrong to me. As far as I know, the SQL standard does not prohibit to use a (possible) volatile value expression for window function's arguments (except offset argument of course). So there are a few choices: 1) Cache whether NULL or NOT NULL and reuse even for volatile expressions (current implementation). This produces weird results as you described. 2) Prohibit to use volatile expressions for window functions arguments. This becomes a PostgreSQL's implementation limitation. 3) Give up to use the cache when volatile expressions are used (your patches). For me, #3 seems to be a reasonable choice. > The attached patch makes a small change in that direction. It only uses the IGNORE NULLS nullness cache when the argument is safe to reuse. For non-cacheable arguments, the nullness is treated as unknown and the argument is evaluated again. > > See the attached patch for details. I will look into the patches. Regards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp