Re: Modest proposal for making bpchar less inconsistent

On Fri, Sep 13, 2019 at 09:50:10PM +0200, Pavel Stehule wrote:
>
>
> Dne pá 13. 9. 2019 16:43 uživatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
>
> 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.
>
>
> has sense

Yes, I think this is a great idea!

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +