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! -- Bruce Momjian <br...@momjian.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 +
