Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ek9kv-0005gJ-A9 for pgsql-sql@arkaria.postgresql.org; Fri, 09 Feb 2018 14:34:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ek9kt-00039h-Bn for pgsql-sql@arkaria.postgresql.org; Fri, 09 Feb 2018 14:34:23 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ek9kt-00039X-5r for pgsql-sql@lists.postgresql.org; Fri, 09 Feb 2018 14:34:23 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ek9kp-0002Dt-JA for pgsql-sql@postgresql.org; Fri, 09 Feb 2018 14:34:22 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w19EWGO5001003; Fri, 9 Feb 2018 09:32:16 -0500 From: Tom Lane To: "David G. Johnston" cc: itdev@itdevel.internal.net, pgsql-sql Subject: Re: functions allowed in CHECK constraints In-reply-to: References: <8d319874-ea46-d44f-29df-b6ecde7ce9c4@itdevel.internal.net> Comments: In-reply-to "David G. Johnston" message dated "Fri, 09 Feb 2018 06:58:52 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1001.1518186736.1@sss.pgh.pa.us> Date: Fri, 09 Feb 2018 09:32:16 -0500 Message-ID: <1002.1518186736@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk "David G. Johnston" writes: > On Fri, Feb 9, 2018 at 1:37 AM, Achilleas Mantzios < > itdev@itdevel.internal.net> wrote: >> So, what's the point in forbidding the use of subselects if one can use >> functions? And OTOH if effectively doing so is bad for some reason, why let >> it happen with a function? > Short answer, the system treats the function as a black-box and doesn't > know that you've used it to circumvent its prohibition on subselects. The > prohibition still is in place though. If you use a function you are > expected to ensure you do not violate any of the restrictions yourself. Actually, I'd say that the possibility to use a function is a workaround for the fact that you can't write a sub-select directly ;-). The latter is more of an implementation restriction than anything else, stemming from the fact that we don't run CHECK expressions through the planner. Now, it's certainly true that you can use a sub-select to write a non-immutable CHECK expression and thereby shoot yourself in the foot. But you can shoot yourself in the foot that way without sub-selects, too. We do not try to enforce that CHECK expressions are immutable. regards, tom lane