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 1qTl4l-00AZYX-FU for pgsql-bugs@arkaria.postgresql.org; Wed, 09 Aug 2023 15:26:19 +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 1qTl4j-006Lkk-Fb for pgsql-bugs@arkaria.postgresql.org; Wed, 09 Aug 2023 15:26:17 +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 1qTl4j-006Lkb-7b for pgsql-bugs@lists.postgresql.org; Wed, 09 Aug 2023 15:26:17 +0000 Received: from [68.162.161.243] (helo=sss.pgh.pa.us) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qTl4g-001PvY-IK for pgsql-bugs@lists.postgresql.org; Wed, 09 Aug 2023 15:26:16 +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 379FQCV8101254; Wed, 9 Aug 2023 11:26:12 -0400 From: Tom Lane To: David Rowley cc: Nicolas Gouteux , "David G. Johnston" , "pgsql-bugs@lists.postgresql.org" Subject: Re: BUG #18051: char(N) and varchar(N) behave opposite to the documentation In-reply-to: References: <18051-3d2890ce9127a33a@postgresql.org> Comments: In-reply-to David Rowley message dated "Thu, 10 Aug 2023 03:03:19 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <101252.1691594772.1@sss.pgh.pa.us> Date: Wed, 09 Aug 2023 11:26:12 -0400 Message-ID: <101253.1691594772@sss.pgh.pa.us> X-Host-Lookup-Failed: Reverse DNS lookup failed for 68.162.161.243 (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk David Rowley writes: > Anyway, 2004 was a long time ago. I can't imagine we could possibly > make such a change today to put it back. Yeah. IMV, char(N) is a legacy type with legacy behaviors, and we shouldn't change those behaviors for fear of breaking legacy applications that might expect them. If you don't like the way it works, don't use char(N). BTW, as far as the question of better optimization of fixed-width fields goes, we couldn't do that anyway with char(N) except in the ever-more-minority case of single-byte database encoding. That's because N is counted in characters not bytes (as is quite clear from the SQL standard, even if their opinion about trailing spaces is less clear). I think that's a primary reason why nobody has bothered to pursue such an optimization, and in turn that's why char(N) is now such a backwater. regards, tom lane