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 1wGFnc-0062WR-1s for pgsql-bugs@arkaria.postgresql.org; Fri, 24 Apr 2026 12:38:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wGFnb-006RcM-2V for pgsql-bugs@arkaria.postgresql.org; Fri, 24 Apr 2026 12:38:23 +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 1wGF9j-006BPu-0R for pgsql-bugs@lists.postgresql.org; Fri, 24 Apr 2026 11:57:11 +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 1wGF9f-00000002ZRG-1gjj for pgsql-bugs@lists.postgresql.org; Fri, 24 Apr 2026 11:57:10 +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=Cq1tMfmjvcokASzyuZPw4zsOE3O2Jo3U8bE7vod//Vg=; b=QwkunUt3vD/l+hHOIGvEDgGzD0 uZflq4d58VSEG983zVAQSS+/k2K0uLLDhMXJYcszKbTOKTRRJvNSkX44VahIJ+2P1qprRRIKgxe3O ZRhblh6QH9al4M0hq7N+8JDYTWfv5gb5KenV2Og+jfvmmjjN6/StQHY9gJPn51bIucOEsUIrRr0mh QGJeJ7KnduNclSMn8ajwWhp2cZtpmC6ccs3iPRb+6d7Y556BxrXTuAqXzrvWWgf1qRBaqDPliac1H 7oom6HLxvPZdrjCF8fQUstibyKKuT2KJHoJkdKInA1TZW1xRnRJpa0+jgHIOuEUBZtOXdPadJfB+d 5J6ZgiIQ==; 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 1wGF9c-007mac-2J for pgsql-bugs@lists.postgresql.org; Fri, 24 Apr 2026 11:57:06 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wGF9a-00H70V-28 for pgsql-bugs@lists.postgresql.org; Fri, 24 Apr 2026 11:57:03 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: BUG #19465: Inconsistency in EXP(LN(x)) equivalence leading to different COUNT result in PostgreSQL To: pgsql-bugs@lists.postgresql.org From: PG Bug reporting form Cc: fmusqlgen@163.com Reply-To: fmusqlgen@163.com, pgsql-bugs@lists.postgresql.org Date: Fri, 24 Apr 2026 11:56:38 +0000 Message-ID: <19465-0e3f9ab09f98be28@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: 19465 Logged by: Jasper Andrew Email address: fmusqlgen@163.com PostgreSQL version: 18.1 Operating system: Ubuntu 24.04 LTS x86_64 Description: =20 The following query produces inconsistent results across different database systems. When executed on MySQL, DuckDB, and MonetDB, the result is 0. However, on PostgreSQL, the same query returns 5. ```SQL SELECT COUNT(*) FROM users AS ref_0 WHERE (SELECT VAR_SAMP(id) FROM posts) <> EXP(LN((SELECT VAR_SAMP(id) FROM posts))); ``` Notes The expression EXP(LN(x)) is mathematically equivalent to x, so the comparison should evaluate to false when both subqueries return the same value. Other database systems seem to treat this equivalence as exact (or sufficiently precise), resulting in COUNT(*) =3D 0. PostgreSQL appears to produce a different result, possibly due to differences in: - floating-point precision - numeric type handling - implementation of VAR_SAMP, LN, or EXP Is this behavior expected due to floating-point precision differences, or does it indicate a potential bug in PostgreSQL? Steps to reproduce ```SQL -- SCHEMA CREATE TABLE users ( id INT, username VARCHAR(100), email VARCHAR(255), age INT, status VARCHAR(20), created_at TIMESTAMP, score DOUBLE PRECISION ); CREATE TABLE posts ( id INT, user_id INT, title VARCHAR(255), content VARCHAR(1000), views INT, likes INT, created_at TIMESTAMP, rating DOUBLE PRECISION ); INSERT INTO users VALUES (1, 'alice', 'alice@test.com', 20, 'active', '2022-01-01 10:00:00', 88.5), (2, 'bob', 'bob@test.com', 30, 'active', '2022-01-02 11:00:00', 92.3), (3, 'carol', NULL, NULL, 'banned','2022-01-03 12:00:00', NULL), (4, 'dave', 'dave@test.com', 45, 'active', '2022-01-04 13:00:00', 65.2), (5, NULL, 'null@test.com', 18, 'inactive','2022-01-05 14:00:00', 70.0); INSERT INTO posts VALUES (1, 1, 'Hello World', 'First post', 100, 10, '2022-01-10 10:00:00', 4.5), (2, 1, 'Another Post', NULL, 150, 20, '2022-01-11 11:00:00', 3.0), (3, 2, 'Bob Post', 'Content', NULL, 5, '2022-01-12 12:00:00', NULL), (4, 3, NULL, 'Empty', 50, 2, '2022-01-13 13:00:00', 5.0), (5, 4, 'Last Post', 'Last', 300, 30,'2022-01-14 14:00:00', 4.9); -- TRIGGER SQL SELECT COUNT(*) FROM users AS ref_0 WHERE (SELECT VAR_SAMP(id) FROM posts) <> EXP(LN((SELECT VAR_SAMP(id) FROM posts))); -- RESULT: {5} Wrong! ```