Thread: text and varchar are not equivalent
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/datatype-character.html Description: 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. CREATE TEMPORARY TABLE test(ch char, vc varchar, txt text, txt0 text); INSERT INTO test VALUES (' ', ' ', ' ',''); SELECT ch = vc AS ch_vc, ch = txt AS ch_txt, ch = txt0 AS ch_txt0, vc = ch AS vc_ch, vc = txt AS vc_txt, vc = txt0 AS vc_txt0, txt = ch AS txt_ch, txt = vc AS txt_vc, txt = txt0 AS txt_txt0, txt0 = ch AS txt0_ch, txt0 = vc AS txt0_vc, txt0 = txt AS txt0_txt FROM test; ch_vc ch_txt ch_txt0 vc_ch vc_txt vc_txt0 txt_ch txt_vc txt_txt0 txt0_ch txt0_vc txt0_txt TRUE FALSE TRUE TRUE TRUE FALSE FALSE TRUE FALSE TRUE FALSE FALSE The tests are showing that the space character is treated differently in a one character string. Whilst varchar = text, the comparison with char is treated differently with text and varchar
On Fri, Feb 9, 2024, 10:12 PG Doc comments form <noreply@postgresql.org> wrote:
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/16/datatype-character.html
Description:
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.
David J.
"David G. Johnston" <david.g.johnston@gmail.com> writes: > On Fri, Feb 9, 2024, 10:12 PG Doc comments form <noreply@postgresql.org> > 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