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
