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 1wzwAa-004LcO-00 for pgsql-bugs@arkaria.postgresql.org; Fri, 28 Aug 2026 12:58:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wzw9Y-007XuI-1M for pgsql-bugs@arkaria.postgresql.org; Fri, 28 Aug 2026 12:57:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wzoDF-005lIv-1g for pgsql-bugs@lists.postgresql.org; Fri, 28 Aug 2026 04:29:09 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wzoDC-00000001fI6-1PUy for pgsql-bugs@lists.postgresql.org; Fri, 28 Aug 2026 04:29:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:Cc:From:To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:Sender:Content-ID: Content-Description:In-Reply-To:References; bh=2K+n3dOInbaiPGC460N7yt/WwJxH++Gog98wRCA4Khw=; b=RnItoKXyKipgVDIK4wuPsXSrZG oCNpfjLWRMBNIs/VYDZjmq+AXakVzuSsYyh+Gwb+O9h1VqA9iC88vqkxqp+qGR0E3vcbTLoojYIsC oeceTjQjPCGGR6B1tspxq4CvyIzW3UH5xf/PXJIBJdYOUV6LuDS+B1ramXHuNC0dWW+fK/5cpC2YL 6CfFVUIez4RKTZuKQdnp549nP8i6BqaiLvXVA7SKHC5wwprURWcpXqrbhZzAq2iQ50rwa4jw8Lhnb 2jk9c6/FF0hujBuOmMlPpSrOjmqQKmikxUkXV/msoqN9h830OWM3wp5bhQSmJoshBaINOC/whHhfp Cp2LUutw==; Received: from wrigleys.postgresql.org ([2a02:16a8:dc51::60]) by mahout.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wzoDB-008S8l-0E for pgsql-bugs@lists.postgresql.org; Fri, 28 Aug 2026 04:29:05 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1wzoD9-00000005Abh-2ewl for pgsql-bugs@lists.postgresql.org; Fri, 28 Aug 2026 04:29:03 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: BUG #19642: Include column name in error message when varchar(n) length limit is exceeded To: pgsql-bugs@lists.postgresql.org From: PG Bug reporting form Cc: killerwzb@gmail.com Reply-To: killerwzb@gmail.com, pgsql-bugs@lists.postgresql.org Date: Fri, 28 Aug 2026 04:28:42 +0000 Message-ID: <19642-5e93d3e409f1387c@postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk The following bug has been logged on the website: Bug reference: 19642 Logged by: zhibin wang Email address: killerwzb@gmail.com PostgreSQL version: 18.4 Operating system: centos7 Description: =20 Dear PostgreSQL Developers, I am writing to suggest an improvement to the error reporting mechanism for data type length constraints. Currently, when an insertion fails due to exceeding the varchar(n) limit, the error message only states that the value is too long for the type, but it does not specify which column caused the failure. 1. Current Behavior: When executing: CREATE TABLE users ( id SERIAL PRIMARY KEY, username VARCHAR(10) NOT NULL, email VARCHAR(255) ); INSERT INTO users (username) VALUES ('123456789012'); -- 12 chars The error returned is: ERROR: value too long for type character varying(10) 2. The Pain Point: In tables with many columns (e.g., a wide table with 50+ columns), or when performing bulk inserts via ORM/ETL tools, it is often difficult to immediately identify which specific column triggered this generic error. Developers have to manually check the length of every input field against the schema definition. 3. Suggestion: It would be extremely helpful if the error message could explicitly include the column name. Proposed Error Message Format: ERROR: value too long for column "username" (type character varying(10)) Or alternatively: ERROR: value too long for type character varying(10) in column "username" 4. Benefits: Faster Debugging: Developers can instantly locate the problematic field without guessing. Better UX for Tools: GUI clients and ORMs can parse this error more accurately to highlight the specific field in the UI. Thank you for considering this suggestion to improve the developer experience! Best regards, Zhibin Wang.