Re: Problem with a Pettern Matching Check
От | Tom Lane |
---|---|
Тема | Re: Problem with a Pettern Matching Check |
Дата | |
Msg-id | 18684.1124151683@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Problem with a Pettern Matching Check (Michael Fuhr <mike@fuhr.org>) |
Ответы |
Re: Problem with a Pettern Matching Check
|
Список | pgsql-sql |
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
В списке pgsql-sql по дате отправления: