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.94.2) (envelope-from ) id 1tItEf-00HI4A-Bt for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Dec 2024 17:32:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tItEc-001piU-Gd for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Dec 2024 17:32: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.94.2) (envelope-from ) id 1tItEc-001piG-6R for pgsql-hackers@lists.postgresql.org; Wed, 04 Dec 2024 17:32:23 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tItEa-0012jE-V2 for pgsql-hackers@postgresql.org; Wed, 04 Dec 2024 17:32:22 +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 4B4HWDQZ2369349; Wed, 4 Dec 2024 12:32:13 -0500 From: Tom Lane To: Tomas Vondra cc: Amit Langote , Robert Haas , Alvaro Herrera , Andres Freund , Daniel Gustafsson , David Rowley , PostgreSQL Hackers , Thom Brown Subject: Re: generic plans and "initial" pruning In-reply-to: <684c70d7-180e-461d-9377-600c2db581ba@vondra.me> References: <54c35fb9-da3a-4754-ab8c-46ed0b612465@vondra.me> <684c70d7-180e-461d-9377-600c2d! b581ba@vondra.me> Comments: In-reply-to Tomas Vondra message dated "Wed, 04 Dec 2024 18:20:23 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2369347.1733333533.1@sss.pgh.pa.us> Date: Wed, 04 Dec 2024 12:32:13 -0500 Message-ID: <2369348.1733333533@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Tomas Vondra writes: > I'm not forcing you to do elog, if you think ereport() is better. I'm > only asking because AFAIK the "policy" is that ereport is for cases that > think can happen (and thus get translated), while elog(ERROR) is for > cases that we believe shouldn't happen. The proposed coding looks fine from that perspective, because it uses errmsg_internal and errdetail_internal which don't give rise to translatable strings. Having said that, if we think this is a "can't happen" case then it's fair to wonder why go to such lengths to format it prettily. Also, I'd argue that the error message style guidelines still apply, but this errdetail doesn't conform. regards, tom lane