Re: Modest proposal for making bpchar less inconsistent

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