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 1vU5Fd-00Ge06-16 for pgsql-bugs@arkaria.postgresql.org; Fri, 12 Dec 2025 15:40:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vU5Fb-008UUO-2x for pgsql-bugs@arkaria.postgresql.org; Fri, 12 Dec 2025 15:40:12 +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 1vU5Fb-008UUG-25 for pgsql-bugs@lists.postgresql.org; Fri, 12 Dec 2025 15:40:12 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vU5Fa-000Mgk-0A for pgsql-bugs@lists.postgresql.org; Fri, 12 Dec 2025 15:40:12 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 5BCFdt3H994717; Fri, 12 Dec 2025 10:39:55 -0500 From: Tom Lane To: Kirill Reshke cc: keeshd@keeshinds.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #19352: SQL Error messages do not include schema name along with table or data object name. In-reply-to: References: <19352-51c017bf5177cadd@postgresql.org> Comments: In-reply-to Kirill Reshke message dated "Fri, 12 Dec 2025 14:00:52 +0500" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <994715.1765553995.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Fri, 12 Dec 2025 10:39:55 -0500 Message-ID: <994716.1765553995@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Kirill Reshke writes: > On Fri, 12 Dec 2025 at 13:33, PG Bug reporting form > wrote: >> Ideally this error message would be clearer if the schema name was included >> with the data table or object name. > So, if we do anything about this, we need to change all of these > places... This is a big amount of work and would be HEAD-only. Yeah, at a guess we'd be talking about touching a couple of thousand places if we were to apply such a policy uniformly. This has been debated in the past and the answer has always come out "no"; not just because of the work, but because it'd make errors more verbose but frequently not more helpful. As Álvaro notes nearby, we do have provisions for reporting associated schema names as secondary error fields, although I think that's only been implemented in a few dozen places. regards, tom lane