Thread: Should there be a charcat?
Column | Type | Modifiers --------+---------------+-----------c | character(20) | decibel=# select c, c || ('x'::char) from c; c | ?column? ----------------------+----------x | xx I would think that c || 'x' would result in 'x x', but it doesn't because the only text concatenationfunction we have is textcat(text, text). As soon as you cast a char to text, you lose all the trailing spaces. Is this what the spec says should happen? -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
"Jim C. Nasby" <jim@nasby.net> writes: > I would think that c || 'x' would result in 'x x', > but it doesn't We did it that way up through 7.3, but changed because we concluded the behavior was inconsistent. The behavior of char(N) these days is that the padding spaces are not semantically significant, which means that they effectively are not there for anything except display purposes. If we didn't do this, we would have situations where, for example, A = B but (A || 'x') != (B || 'x'). Does that strike you as a good idea? If you're interested you can probably find more discussion in the archives from mid-2003 or so. regards, tom lane
On Fri, Oct 06, 2006 at 04:10:42PM -0400, Tom Lane wrote: > "Jim C. Nasby" <jim@nasby.net> writes: > > I would think that c || 'x' would result in 'x x', > > but it doesn't > > We did it that way up through 7.3, but changed because we concluded the > behavior was inconsistent. The behavior of char(N) these days is that > the padding spaces are not semantically significant, which means that > they effectively are not there for anything except display purposes. Nah, I've just always thought of the spaces as being significant. Then again, I tend to avoid char, so... > If we didn't do this, we would have situations where, for example, > A = B but (A || 'x') != (B || 'x'). Does that strike you as a good idea? > > If you're interested you can probably find more discussion in the > archives from mid-2003 or so. > > regards, tom lane > -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)