Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q9oII-0000R4-JX for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Jun 2023 14:49:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q9oIG-00083D-Lg for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Jun 2023 14:49:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q9oIG-000834-CR for pgsql-hackers@lists.postgresql.org; Thu, 15 Jun 2023 14:49:48 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q9oID-002YAg-J4 for pgsql-hackers@lists.postgresql.org; Thu, 15 Jun 2023 14:49:47 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 35FEn1He2131669; Thu, 15 Jun 2023 10:49:01 -0400 From: Tom Lane To: "David G. Johnston" cc: "chap@anastigmatix.net" , Yura Sokolov , "pgsql-hackers@lists.postgresql.org" Subject: Re: When IMMUTABLE is not. In-reply-to: References: <389c986d-fbb4-c644-9280-db7836af7ca9@postgrespro.ru> <2111925.1686835298@sss.pgh.pa.us> <69234e25e34e68425f49630f79ef9991@anastigmatix.net> <4c32f84bc097dee0081e4cc3e733ef8d@anastigmatix.net> Comments: In-reply-to "David G. Johnston" message dated "Thu, 15 Jun 2023 07:19:39 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2131667.1686840541.1@sss.pgh.pa.us> Date: Thu, 15 Jun 2023 10:49:01 -0400 Message-ID: <2131668.1686840541@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > The failure to find and execute the function code itself is not a failure > mode that these markers need be concerned with. Assuming one can execute > the function an immutable function will give the same answer for the same > input for all time. The viewpoint taken in the docs I mentioned is that an IMMUTABLE marker is a promise from the user to the system about the behavior of a function. While the system does provide a few simple tools to catch obvious errors and to make it easier to write functions that obey such promises, it's mostly on the user to get it right. In particular, we've never enforced that an immutable function can't call non-immutable functions. While that would seem like a good idea in the abstract, we've intentionally not tried to do it. (I'm pretty sure there is more than one round of previous discussions of the point in the archives, although locating relevant threads seems hard.) One reason not to is that polymorphic functions have to be marked with worst-case volatility labels. There are plenty of examples of functions that are stable for some input types and immutable for others (array_to_string, for instance); but the marking system can't represent that so we have to label them stable. Enforcing that a user-defined immutable function can't use such a function might just break things for no gain. regards, tom lane