Michael Fuhr <mike@fuhr.org> writes:
> The CHAR(3) specification causes the value to be space-padded, so
> '1' becomes '1 ' (the digit "one" followed by two spaces).
Actually, we seem to be going out of our way to make this case fail.
Given that we consider trailing spaces in char(n) to be semantically
insignificant, would it make sense to strip them before doing the
regex pattern match? That would happen automatically if we allowed
the char(n) value to promote to text --- and the only reason it's
not doing so is that there's an extra ~ operator definition that
specifically prevents that (bpcharregexeq).
I have a feeling that we added that operator definition at some point
for backwards compatibility, but it seems a bit odd now.
regards, tom lane