Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lbb6r-0007Wl-4U for pgsql-bugs@arkaria.postgresql.org; Wed, 28 Apr 2021 03:43:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lbb6p-0006kv-NT for pgsql-bugs@arkaria.postgresql.org; Wed, 28 Apr 2021 03:43:31 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lbb6p-0006ko-HJ for pgsql-bugs@lists.postgresql.org; Wed, 28 Apr 2021 03:43:31 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lbb6j-00024C-Bu for pgsql-bugs@lists.postgresql.org; Wed, 28 Apr 2021 03:43:30 +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 13S3hAGA2761426; Tue, 27 Apr 2021 23:43:10 -0400 From: Tom Lane To: Bruce Momjian cc: Alvaro Herrera , Gavin Flower , Noah Misch , neverov.max@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #16939: Plural interval for negative singular In-reply-to: <2753264.1619568545@sss.pgh.pa.us> References: <20210427234438.GA22943@alvherre.pgsql> <2753264.1619568545@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Tue, 27 Apr 2021 20:09:05 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2761424.1619581390.1@sss.pgh.pa.us> Date: Tue, 27 Apr 2021 23:43:10 -0400 Message-ID: <2761425.1619581390@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > Hm. We actually document PQprint. While the other two entry points > in that file aren't documented, they are listed in exports.txt, > which means somebody *could* be calling them. I think we'd at least > have to go through a long deprecation period before we could consider > removing them. Meanwhile, returning to the point at hand in this thread: AFAICS from a quick review of the git logs, the last intentional changes of user-visible behavior in fe-print.c were more than 20 years ago. Since then it's only seen in-passing bug fixes, such as libpq-wide fixes of signal handling. So, to the extent that this code has any use at all it's for legacy applications. I don't think we should be making random changes in its behavior for at-best-weak reasons. In short, I'm now a vote to revert every single bit of 5da9868ed. regards, tom lane