Re: Modest proposal for making bpchar less inconsistent

At Sat, 28 Sep 2019 08:22:22 -0400, Bruce Momjian <bruce(at)momjian(dot)us> wrote in <20190928122222(dot)GA26853(at)momjian(dot)us>
> 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!

I totally agree.

--
Kyotaro Horiguchi
NTT Open Source Software Center