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 1pgSn5-0004qZ-Oh for pgsql-novice@arkaria.postgresql.org; Sun, 26 Mar 2023 16:00:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pgSn3-0003BM-R6 for pgsql-novice@arkaria.postgresql.org; Sun, 26 Mar 2023 16:00:17 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pgSn3-0003BD-IS for pgsql-novice@lists.postgresql.org; Sun, 26 Mar 2023 16:00:17 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pgSmx-0004VF-47 for pgsql-novice@lists.postgresql.org; Sun, 26 Mar 2023 16:00:16 +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 32QG05c92914599; Sun, 26 Mar 2023 12:00:05 -0400 From: Tom Lane To: "David G. Johnston" cc: Valerio Battaglia , "pgsql-novice@lists.postgresql.org" Subject: Re: How to get column, table or parameter name reporting when violating DOMAIN type constraint In-reply-to: References: <2911010.1679844383@sss.pgh.pa.us> Comments: In-reply-to "David G. Johnston" message dated "Sun, 26 Mar 2023 08:36:58 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2914597.1679846405.1@sss.pgh.pa.us> Date: Sun, 26 Mar 2023 12:00:05 -0400 Message-ID: <2914598.1679846405@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Sunday, March 26, 2023, Tom Lane wrote: >> More to the point, you have the wrong mental model: a domain constraint >> violation might not be associated with a table column at all. > I disagree that the mental model is wrong. The OP is asking for action-at-a-distance. There are probably cases where the distance is short enough that we could associate the runtime error with a particular insertion target column, but I don't think it could possibly be made to work for every sort of insert/select query. In any case, the possibility of a hypothetical future feature (which nobody is actively working on AFAIK) doesn't seem like a very useful answer here. > There are existing threads that I may hunt later. IIRC, you (Tom) even > suggested a possible way forward on this last time it came up. I recall proposing that we try to produce syntax-error-like error cursors for runtime errors, but it's not apparent to me that that'd be tremendously applicable to the OP's problem. The output would look something like ERROR: value for domain my_domain violates check constraint "value_min" LINE 1: SELECT my_function(100, -100); ^ which might be helpful for a human, but probably not very much so for a program. (BTW, this illustrates another issue: I'm pretty sure that in the given case, the error is thrown while evaluating my_function's arguments, long before we get within hailing distance of any INSERT at all.) regards, tom lane