It struck me that the real reason that we keep getting gripes about the weird behavior of CHAR(n) is that these functions (and, hence, their corresponding operators) fail to obey the "trailing blanks aren't significant" rule:
regprocedure | prosrc -------------------------------------------+---------------------- bpcharlike(character,text) | textlike bpcharnlike(character,text) | textnlike bpcharicregexeq(character,text) | texticregexeq bpcharicregexne(character,text) | texticregexne bpcharregexeq(character,text) | textregexeq bpcharregexne(character,text) | textregexne bpchariclike(character,text) | texticlike bpcharicnlike(character,text) | texticnlike They're just relying on binary compatibility of bpchar to text ... but of course textlike etc. think trailing blanks are significant. Every other primitive operation we have for bpchar correctly ignores the trailing spaces. We could fix this, and save some catalog space too, if we simply deleted these functions/operators and let such calls devolve into implicit casts to text. This might annoy people who are actually writing trailing spaces in their patterns to make such cases work. But I think there are probably not too many such people, and having real consistency here is worth something. regards, tom lane