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 1pgO1K-0008Po-O5 for pgsql-novice@arkaria.postgresql.org; Sun, 26 Mar 2023 10:54:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pgO1H-0004OQ-Eh for pgsql-novice@arkaria.postgresql.org; Sun, 26 Mar 2023 10:54:39 +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 1pgO1H-0004OH-4a for pgsql-novice@lists.postgresql.org; Sun, 26 Mar 2023 10:54:39 +0000 Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pgO1A-0005IV-Fw for pgsql-novice@lists.postgresql.org; Sun, 26 Mar 2023 10:54:38 +0000 Received: by mail-lf1-x135.google.com with SMTP id g17so7704317lfv.4 for ; Sun, 26 Mar 2023 03:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679828070; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=yDNi/u0cph9syjID45ieag8BO1/z4IL4QgKOwWJqLqM=; b=h6PC6wGO60tO/z9Y7Kd3eQ02mpN0xWoCUNx3tm71JNW3QnwiDcI7rEWwu1y1srso5g 6sI2+Z9ZasRECfz/ha/gWDu1NCOxZdTa5H8io+tTvtG4ytA6fiL5/03APjXymwBFfhRP K4ODtjSAd2k7h912p6ZG+IVIRHJ8BLgLp/GkXvAP7g7U8ukeRTUy3mDdVKgeXs+NdsM2 3FeQX12ilZoMHd/ycKrnQ50CvXReKg/BDNj09JS0bLBtA/uP9cAzTSrePjCl69/2Qzym gBYoJwgE4PdFXjF80dFfON56ZZMg3C6SocC1Xgar1+MHo0LxWB4YytnfgnLUH4YDNq/H dRGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679828070; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=yDNi/u0cph9syjID45ieag8BO1/z4IL4QgKOwWJqLqM=; b=ukUtl8HuXgC0VsSOqQppmRDSM7oH7deZdV/dIsmTSKHHsohNw3M3EDmM1KeS70x2z/ Wf3GzwtKS6AM9r8CeHYUnjOQKP6aMqwXMhmQ2mdEQkGYyiSXU6fwHK8S3UB6DDIQaBaH q8tWgbrfi0gJioEbtlXLCT74Q8rC2Lg0N52h7j4kgfJRIkvCm+3t2+Cw1QxURL1ZYTfu sgsCo3jhusPdLf4MmhAwRaNuMTlxj9mADHQpVIBH7NN+j1hyW9eVkwfvL7SmM6KBJ/TN RNO2Pr5wW0ndxajZHtcDAqdAcS8rTn8jaUVvY81PZ3KlbM4RnNUXysV3d7IGrZDdBwNY 32OA== X-Gm-Message-State: AAQBX9dxLf2dWK9rTEucY54gc7s/6NkKrxT4dsgGqlj3JdFrUrsYGHs/ mM503De3XZWjPQg4p/I32BL2V4b6E6xk26rHp0omm9PcXxRbwA== X-Google-Smtp-Source: AKy350YzVhUhEKA8MuV61RCjLuHVaJqaqMdx0tRm8IoZ2Ep1T81cgvg7VShH5XCxAt3sXqXx7vD+AAtD5t+p2w7rd5k= X-Received: by 2002:ac2:5448:0:b0:4e9:bcf5:a0b6 with SMTP id d8-20020ac25448000000b004e9bcf5a0b6mr2264129lfn.11.1679828069976; Sun, 26 Mar 2023 03:54:29 -0700 (PDT) MIME-Version: 1.0 From: Valerio Battaglia Date: Sun, 26 Mar 2023 12:54:18 +0200 Message-ID: Subject: How to get column, table or parameter name reporting when violating DOMAIN type constraint To: pgsql-novice@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000650d4d05f7cb7386" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000650d4d05f7cb7386 Content-Type: text/plain; charset="UTF-8" Hi, I am reaching out to request assistance with obtaining column, table or parameter name when a DOMAIN type constraint is violated in PostgreSQL. Specifically, I am looking for a way to easily identify the column or parameter that is causing the constraint violation, so that I can have better error / validation reporting in the client. Imagine the following SQL code: CREATE DOMAIN my_domain AS integer CONSTRAINT value_min CHECK (VALUE > 0) CONSTRAINT value_max CHECK (VALUE <= 200); CREATE FUNCTION my_function(first_parameter my_domain, second_parameter my_domain) RETURNS void AS $$BEGIN INSERT INTO my_table (first_column, second_column) VALUES (first_parameter, second_parameter);END; $$ LANGUAGE plpgsql; When I call this function with a value that violates the DOMAIN type constraint, I receive the following error message: SELECT my_function(100, -100); -- ERROR: value for domain my_domain violates check constraint "value_min" However, this error message does not provide any information about which column or parameter is causing the constraint violation. The same scenario applies when calling the INSERT INTO statement directly as well. Is there a way to obtain more detailed information about the column, table or parameter that is causing the constraint violation in this scenario? I would greatly appreciate any guidance or advice you could provide on this matter. Thanks --000000000000650d4d05f7cb7386 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am reaching out to request as= sistance with obtaining column, table or=20 parameter name when a DOMAIN type constraint is violated in PostgreSQL.=20 Specifically, I am looking for a way to easily identify the column or=20 parameter that is causing the constraint violation, so that I can have bett= er error / validation reporting in the client.

Imagine the fol= lowing SQL code:
CREATE DOMAIN m=
y_domain AS integer
CONSTRAINT value_min CHECK (VALUE > 0)
CONSTRAINT value_max CHECK (VALUE <=3D 200); CREATE FUNCTION my_function(first_parameter my_domain, second_para= meter my_domain) RETURNS void AS $$ BEGIN INSERT INTO my_table (first_column, second_column) VALUES (first_parameter, second_parameter); END; $$ LANGUAGE plpgsql;
When I call this function with a value that violates the= DOMAIN type constraint, I receive the following error message:
<= pre>SEL= ECT my_function(100, -100);
-- ERROR: value for domain my_doma= in violates check constraint "value_min"

However, this error message does not provide any= information about which column or parameter is causing the constraint viol= ation. The same scenario applies when calling the INSERT INTO statement dir= ectly as well.

Is there a way to obtain more detailed information= about the column, table or parameter that is causing the constraint violat= ion in this scenario? I would greatly appreciate any guidance or advice you= could provide on this matter.

Thanks

--000000000000650d4d05f7cb7386--