At Sat, 28 Sep 2019 08:22:22 -0400, Bruce Momjian <br...@momjian.us> wrote in <20190928122222.ga26...@momjian.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 <t...@sss.pgh.pa.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
