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 1w7B9z-0052P7-1K for pgsql-bugs@arkaria.postgresql.org; Mon, 30 Mar 2026 11:51:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w7B9x-002snY-28 for pgsql-bugs@arkaria.postgresql.org; Mon, 30 Mar 2026 11:51:58 +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 1w730w-000gEA-1E for pgsql-bugs@lists.postgresql.org; Mon, 30 Mar 2026 03:10: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 1w730u-00000001jnn-2W0z for pgsql-bugs@lists.postgresql.org; Mon, 30 Mar 2026 03:10: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=rafKot5Wq+g3DlSGqtgUKZi2bEwdntDX/JjCG2lM290=; b=NUYNINesc9Bgxn5mIT/p5WoV2g K/v1oCKeJlD0TxofxJGwwEeFtnTUgvMpDQCFL+ffu9TtniiwndZrjPQhinNsYHqh7jFmUtdtC7yuT 5G9AIbwdQHCvpej5fbwRcZXkhrV8IpG6qQXtPPxLfZLxp9tJF02KoA3x1hmrwF8hleRNpT5s1DfHJ 3i4UPX8sTXgJV5/1C5Nj5XPQOIwjfl3AHL0Qj98y1bbe1Jp1+vE6gRr4oO3BX90h87RGK+1afk1Ka glYEgWASbDNj1XjkP8o3N6PNlMKw98TUn47ggRZONN5dwd+4N+LzM9bnlcVmcMo+ULpFNr27e8BFx EUv8J3CQ==; 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 1w730t-006Z8b-37 for pgsql-bugs@lists.postgresql.org; Mon, 30 Mar 2026 03:10:04 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w730s-00ADS0-0h for pgsql-bugs@lists.postgresql.org; Mon, 30 Mar 2026 03:10:03 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: BUG #19442: PL/pgSQL: domain over composite type bypasses type validation when assigning NULL (PostgreSQL 18.3) To: pgsql-bugs@lists.postgresql.org From: PG Bug reporting form Cc: zheng_xianghang@163.com Reply-To: zheng_xianghang@163.com, pgsql-bugs@lists.postgresql.org Date: Mon, 30 Mar 2026 03:09:12 +0000 Message-ID: <19442-4a6a013c75f2ebbd@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: 19442 Logged by: Xianghang Zheng Email address: zheng_xianghang@163.com PostgreSQL version: 18.3 Operating system: Linux x86_64 Description: =20 I found an issue on PostgreSQL 18.3 related to domain handling over composite types in PL/pgSQL. After the fix for BUG #18735, the "cache lookup failed for type 0" error no longer occurs, but a new correctness problem arises: When assigning a NULL composite variable to a domain over composite type in PL/pgSQL, the domain's type validation and coercion logic is bypassed. This indicates an incomplete fix and may lead to incorrect enforcement of domain constraints (CHECK, NOT NULL, etc.) in the future. Version: PostgreSQL 18.3 Test case: CREATE TYPE comp AS (a int, b text); CREATE DOMAIN dcomp AS comp; CREATE OR REPLACE FUNCTION test_domain_bug() RETURNS dcomp AS $$ DECLARE v_comp comp :=3D NULL; v_dcomp dcomp; BEGIN v_dcomp :=3D v_comp; RETURN v_dcomp; END; $$ LANGUAGE plpgsql; SELECT test_domain_bug(); Actual result: NULL (no error) Expected result: Domain type coercion should be properly executed even for NULL values. This is a regression caused by incomplete backpatch of BUG #18735.