Tom Lane <tgl@xxxxxxxxxxxxx> writes:
> Chris Travers <chris@xxxxxxxxxxxxxxxxxx> writes:
> > If I understand the spec correctly, it seems to indicate that this is
> > specific to the locale/character set.
>
> The spec associates padding behavior with collations, which per spec are
> separate from the datatypes --- that is, you should be able to able to
> specify a collation for each string-type table column (whether char(N)
> or varchar(N)) and even for each literal string constant. We do not
> currently have that capability, and accordingly fall back to binding
> PAD SPACE behavior to char(N) and NO PAD behavior to varchar(N).
>
> AFAICS this choice is allowed by the spec since the default collation is
> implementation-defined.
Does it even make sense for char(N) to not be space padded? I had the
impression char(N) was always N characters long, not more or less. I can't
picture any other character being used for padding, then you would need a more
flexible rtrim function.
And I can understand the collation order determining whether 'a' and 'a '
compare equal. But surely if you store 'a' in a varchar(N) you have to get 'a'
back out, not some other string! Does the spec really allow varchar to
actually be padded and not just compare ignoring trailing space?
(I can't believe anyone really wants varchar to be space padded. Space padding
always seemed like a legacy feature for databases with fixed record length
data types. Why would anyone want a string data type that can't represent all
strings?)
--
greg
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
