From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Modest proposal for making bpchar less inconsistent |
Date: | 2019-09-13 19:50:10 |
Message-ID: | CAFj8pRDRNE8dkWMAW5+x1a-=ye4RoGv9W0zvVp_oKKFwQYuc6g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Pavel
>
> regards, tom lane
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-09-13 20:04:20 | Re: [PATCH] Improve performance of NOTIFY over many databases (v2) |
Previous Message | Alvaro Herrera | 2019-09-13 19:42:47 | Re: Duplicated LSN in ReorderBuffer |