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 1x278p-005asf-17 for pgsql-bugs@arkaria.postgresql.org; Thu, 03 Sep 2026 13:06:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1x278o-000duh-1D for pgsql-bugs@arkaria.postgresql.org; Thu, 03 Sep 2026 13:06:06 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x21F0-00GJj0-2L for pgsql-bugs@lists.postgresql.org; Thu, 03 Sep 2026 06:48:06 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1x21Ez-00000003lRX-0Asd for pgsql-bugs@lists.postgresql.org; Thu, 03 Sep 2026 06:48:05 +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=YL/ljCmRQJoJkzUj9fJCDJhaGycKDF/n1VLiqc4PD9A=; b=Ce3phrYUtH3tX0X7+AgL1QWn2K 39do81QUd/dmwuNeZ1wqq4iiQGXqvSUCmUj5himrkGgnhROgGBEibWrjrR8C54Nf3rhvSnHQ4dgmv bQHLG2aFCkFtBgw3dhORXhT3DPyEpXr8aY/b/DXwsA3QdfTePB0wwj11fVMJs4q/PD7rnq9nB8JLz nlpSBPtB26oLISOpuDoHQls9rgik5xq7IX+kt/mulPYnJzqTBolLX8sNHyvgUL/gN47sSxhQvPfan 1gvvTe5l2JvgYgjDCxnwEkiNV/OwWZG8luOd9CpFN3iNuFrJLQ9L2NM4NMLcIRdiNFP3N5fplikaM mWPv96OQ==; 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 1x21Ey-00BOeb-2c for pgsql-bugs@lists.postgresql.org; Thu, 03 Sep 2026 06:48:04 +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 1x21Ex-0000000D7wU-3Jtr for pgsql-bugs@lists.postgresql.org; Thu, 03 Sep 2026 06:48:03 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: BUG #19652: to_number() silently truncates over-length integers To: pgsql-bugs@lists.postgresql.org From: PG Bug reporting form Cc: 303677365@qq.com Reply-To: 303677365@qq.com, pgsql-bugs@lists.postgresql.org Date: Thu, 03 Sep 2026 06:48:00 +0000 Message-ID: <19652-53cdb1205ea93a19@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: 19652 Logged by: chunling qin Email address: 303677365@qq.com PostgreSQL version: 18.6 Operating system: x86_64 Description: =20 When the number of integer digits exceeds what the format template provides, the excess digits are silently dropped. The very same input with a decimal point added raises an overflow error =E2=80=94 one "value exceeds the forma= t" scenario, two opposite behaviors: SELECT to_number('1234567', '999'); -- 123 (digits beyond the 3-digit format silently discarded) SELECT to_number('1234567.89', '999.99'); -- ERROR: numeric field overflow -- DETAIL: A field with precision 3, scale 0 must round to an absolute value -- less than 10^3. Both inputs should raise an error ("value too long" / overflow), since the integral part exceeds the format in both cases; silently returning 123 for '1234567' loses the high-order digits without any diagnostic.