On Wednesday 18 February 2004 00:25, Tom Lane wrote:
> "scott.marlowe" <scott.marlowe@ihs.com> writes:
> > But then this:
> > select 'x'||' '||'x'
> > should produce xx, but it produces x x.
>
> No, because the imputed type of those literals is text. You'd have to
> cast the middle guy to char(n) explicitly to make its trailing spaces go
> away when it's reconverted to text.
>
> The real issue here is that trailing spaces in char(n) are semantically
> insignificant according to the SQL spec. The spec is pretty vague about
> which operations should actually honor that insignificance --- it's
> clear that comparisons should, less clear about other things. I think
> the 7.4 behavior is more consistent than what we had before, but I'm
> willing to be persuaded to change it again if someone can give an
> alternate definition that's more workable than this one.
[rant on]
I've never really understood the rationale behind char(n) in SQL databases
(other than as backward compatibility with some old mainframe DB).
Insignificant spaces? If it's not significant, why is it there? You could
have a formatting rule that specifies left-aligned strings space-padded (as
printf) but that's not the same as mucking about appending and trimming
spaces.
The only sensible definition of char(n) that I can see would be:
A text value of type char(n) is always "n" characters in length. If you assign
less than "n" characters, it is right-padded with spaces. In all other
respects it behaves as any other text type of length "n" with right-trailing
spaces.
[rant off - ah, feel better for that :-]
-- Richard Huxton Archonet Ltd