Modest proposal for making bpchar less inconsistent

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Modest proposal for making bpchar less inconsistent
Date: 2019-09-13 14:43:18
Message-ID: 21734.1568385798@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2019-09-13 14:51:53 Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Previous Message Nikita Glukhov 2019-09-13 14:20:30 Re: Bug in GiST paring heap comparator