Thread: Handling of pad characters (was RE: Oracle buys Innobase )

Tom Lane wrote:
> Alex Turner <armtuk@gmail.com> writes:
>> It appears that casting to a char() causes spaces to be stripped
>> (ignored) from the string:
> mls=# select length('123 '::char(8));
> length
> --------
> 3
> (1 row)
>
>> I'm not sure about anyone else, but I would personaly consider that a
>> bug?
>
> No, it's a feature, as per extensive discussion some time ago when we
> made it do that.  The general rule is that trailing spaces in a
> char(n) are semantically insignificant.

How did you reach the opposite conclusion for varchar?  If anything, I
would think that stripping pad characters makes more sense for varchar
than it does for char.  But that may simply be bias from experience, as
my first real DBA work was with DB2, where fixed length columns really
are fixed length.

--
Guy Rouillier

"Guy Rouillier" <guyr@masergy.com> writes:
> Tom Lane wrote:
>> No, it's a feature, as per extensive discussion some time ago when we
>> made it do that.  The general rule is that trailing spaces in a
>> char(n) are semantically insignificant.

> How did you reach the opposite conclusion for varchar?  If anything, I
> would think that stripping pad characters makes more sense for varchar
> than it does for char.

But they're not pad characters in varchar --- remember varchar is
implicitly NO PAD (vs char which is implicitly PAD SPACE).

The spec would like us to separate out the PAD attribute from the
datatypes, and eventually we may get around to doing that, but in
the meantime it's hardly likely that we'll drop functionality by
smushing the datatypes together.  Seeing that there's no performance
advantage to char in Postgres, we might as well not have the separate
datatype at all if we're going to give it semantics identical to varchar.

            regards, tom lane