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 1rYV2e-00GIrO-9Y for pgsql-docs@arkaria.postgresql.org; Fri, 09 Feb 2024 17:52:00 +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 1rYV2d-00AZ54-A7 for pgsql-docs@arkaria.postgresql.org; Fri, 09 Feb 2024 17:51:59 +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.94.2) (envelope-from ) id 1rYV2d-00AZ4w-31 for pgsql-docs@lists.postgresql.org; Fri, 09 Feb 2024 17:51:59 +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.94.2) (envelope-from ) id 1rYV2a-006LCp-Jd for pgsql-docs@lists.postgresql.org; Fri, 09 Feb 2024 17:51:58 +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 419Hppk51694199; Fri, 9 Feb 2024 12:51:51 -0500 From: Tom Lane To: "David G. Johnston" cc: harry@harryclarke.me.uk, PostgreSQL Documentation Subject: Re: text and varchar are not equivalent In-reply-to: References: <170747750218.3279716.17734031485916520031@wrigleys.postgresql.org> Comments: In-reply-to "David G. Johnston" message dated "Fri, 09 Feb 2024 10:24:19 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1694197.1707501111.1@sss.pgh.pa.us> Date: Fri, 09 Feb 2024 12:51:51 -0500 Message-ID: <1694198.1707501111@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Fri, Feb 9, 2024, 10:12 PG Doc comments form > wrote: >> The documentation implies that the data types text and varchar are >> equivalent, but this is not the case with this test in Postgresql version >> 16. > Fair point. But I'd rather further emphasize that char should just be > avoided so this and other unexpected outcomes simply do not manifest in a > real database scenario. Rather than try and document how odd it's behavior > is when dealing with intra-textual type conversions. Yeah, this is less about varchar acting oddly and more about char acting oddly. The short answer though is that text is a preferred type, varchar is not, and that makes a difference when resolving whether to apply text's or char's equality operator. You can detect how it's being handled with EXPLAIN: regression=# explain verbose SELECT vc = ch AS vc_ch FROM test; QUERY PLAN --------------------------------------------------------------- Seq Scan on pg_temp.test (cost=0.00..17.88 rows=630 width=1) Output: ((vc)::bpchar = ch) (2 rows) regression=# explain verbose SELECT txt = ch AS txt_ch FROM test; QUERY PLAN --------------------------------------------------------------- Seq Scan on pg_temp.test (cost=0.00..19.45 rows=630 width=1) Output: (txt = (ch)::text) (2 rows) regards, tom lane