Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: BUG #19531: Inconsistent Error Messages for the Same SQL Query
To: pgsql-bugs@lists.postgresql.org
From: PG Bug reporting form <noreply@postgresql.org>
Cc: 1804981203@qq.com
Reply-To: 1804981203@qq.com, pgsql-bugs@lists.postgresql.org
Date: Wed, 24 Jun 2026 07:20:28 +0000
Message-ID: <19531-f13c547b30872910@postgresql.org>
Auto-Submitted: auto-generated
Archived-At: 
 <https://www.postgresql.org/message-id/19531-f13c547b30872910%40postgresql.org>
Precedence: bulk

The following bug has been logged on the website:

Bug reference:      19531
Logged by:          Wang Hao
Email address:      1804981203@qq.com
PostgreSQL version: 18.4
Operating system:   Ubuntu22.04
Description:       =20

Inconsistent Error Messages for the Same SQL Query in PostgreSQL

Environment=EF=BC=9A
- PostgreSQL version: 18.4
- Operating System: Ubuntu 22.04

Context=EF=BC=9A
My application relies on the error messages returned by SQL statement
execution to perform subsequent operations. During development, I discovered
that the same SQL query can return different error messages . I'm not sure
if this is a bug, but it does affect my application's ability to reliably
handle errors.

Steps to Reproduce:
Example 1: Triggering different errors by controlling the execution plan
test=3D# CREATE TABLE t (c1 text DEFAULT '', c2 smallint DEFAULT 0);
CREATE TABLE
test=3D# INSERT INTO t (c1, c2) VALUES ('jkwdot0re', 0);
INSERT 0 1
test=3D# INSERT INTO t (c1, c2) VALUES ('', -1000);
INSERT 0 1
test=3D# SELECT c2 / c2 AS e0, c2 * c2 AS e1 FROM t GROUP BY c1, c2;
ERROR:  division by zero
test=3D# explain(verbose) SELECT c2 / c2 AS e0, c2 * c2 AS e1 FROM t GROUP =
BY
c1, c2;
                            QUERY PLAN
-------------------------------------------------------------------
 HashAggregate  (cost=3D29.65..32.65 rows=3D200 width=3D38)
   Output: (c2 / c2), (c2 * c2), c1, c2
   Group Key: t.c1, t.c2
   ->  Seq Scan on public.t  (cost=3D0.00..23.10 rows=3D1310 width=3D34)
         Output: c1, c2
(5 rows)

test=3D# SET enable_hashagg =3D off;
SET
test=3D# SELECT c2 / c2 AS e0, c2 * c2 AS e1 FROM t GROUP BY c1, c2;
ERROR:  smallint out of range
test=3D# explain(verbose) SELECT c2 / c2 AS e0, c2 * c2 AS e1 FROM t GROUP =
BY
c1, c2;
                               QUERY PLAN
-------------------------------------------------------------------------
 Group  (cost=3D90.93..101.75 rows=3D200 width=3D38)
   Output: (c2 / c2), (c2 * c2), c1, c2
   Group Key: t.c1, t.c2
   ->  Sort  (cost=3D90.93..94.20 rows=3D1310 width=3D34)
         Output: c1, c2
         Sort Key: t.c1, t.c2
         ->  Seq Scan on public.t  (cost=3D0.00..23.10 rows=3D1310 width=3D=
34)
               Output: c1, c2
(8 rows)


Example 2:Triggering different errors due to statistics changes
test=3D# CREATE TABLE t (c1 text DEFAULT '', c2 smallint DEFAULT 0);
CREATE TABLE
test=3D# INSERT INTO t (c1, c2) VALUES ('jkwdot0re', 0);
INSERT 0 1
test=3D# INSERT INTO t (c1, c2) VALUES ('', -1000);
INSERT 0 1
test=3D# SELECT c2 / c2 AS e0, c2 * c2 AS e1 FROM t GROUP BY c1, c2;
ERROR:  division by zero
test=3D# explain(verbose) SELECT c2 / c2 AS e0, c2 * c2 AS e1 FROM t GROUP =
BY
c1, c2;
                            QUERY PLAN
-------------------------------------------------------------------
 HashAggregate  (cost=3D29.65..32.65 rows=3D200 width=3D38)
   Output: (c2 / c2), (c2 * c2), c1, c2
   Group Key: t.c1, t.c2
   ->  Seq Scan on public.t  (cost=3D0.00..23.10 rows=3D1310 width=3D34)
         Output: c1, c2
(5 rows)

test=3D# ANALYZE t;
ANALYZE
test=3D# SELECT c2 / c2 AS e0, c2 * c2 AS e1 FROM t GROUP BY c1, c2;
ERROR:  smallint out of range
test=3D# explain(verbose) SELECT c2 / c2 AS e0, c2 * c2 AS e1 FROM t GROUP =
BY
c1, c2;
                             QUERY PLAN
--------------------------------------------------------------------
 Group  (cost=3D1.03..1.05 rows=3D2 width=3D11)
   Output: (c2 / c2), (c2 * c2), c1, c2
   Group Key: t.c1, t.c2
   ->  Sort  (cost=3D1.03..1.03 rows=3D2 width=3D7)
         Output: c1, c2
         Sort Key: t.c1, t.c2
         ->  Seq Scan on public.t  (cost=3D0.00..1.02 rows=3D2 width=3D7)
               Output: c1, c2
(8 rows)

Observation:
The same SQL query SELECT c2 / c2 AS e0, c2 * c2 AS e1 FROM t GROUP BY c1,
c2; executed against the same data returns two different error messages:
- ERROR: division by zero
- ERROR: smallint out of range
The query contains two expressions that can each trigger an error on the
same data:
- c2 / c2: division by zero when c2 =3D 0
- c2 * c2: smallint overflow when c2 =3D -1000 (since (-1000)=C2=B2 =3D 1,0=
00,000
exceeds the smallint range)
In Example 1, changing enable_hashagg switches the execution plan from
HashAggregate to Group.In Example 2, running ANALYZE updates table
statistics

I'm not certain whether this qualifies as a bug, but it does create a real
problem for applications that depend on consistent error reporting from the
database.Thanks for reading my report!