I will happily reiterate that I am the troll who started this mess by
whining about how *Oracle* handles this. Tom's explanation that CHAR is
has a PAD collation and VARCHAR has a NO PAD collation have restored my
faith that there is goodness in the world. My whining was out of
ignorance. I wouldn't change the proper way PostgreSQL works. Documenting
it is good. I will use this new found knowledge from now on in my database
designs.
Cheers,
Rick
Chris Travers <chris@travelamericas.com> wrote on 10/20/2005 01:52:36 PM:
> Dann Corbit wrote:
>
> >Let me make something clear:
> >When we are talking about padding here it is only in the context of a
> >comparison operator and NOT having anything to do with storage.
> >
> >
> IIrc, varchar and bpchar are stored in a similar way, but are presented
> differently when retrieved. I.e. storage is separate from presentation
> in this case. I.e. the padding in bpchar occurs when it is presented
> and stripped when it is stored.
>
> Again, I am happy "solving" this simply by documenting it since any
> questions of interpretation and implimentation of the standard would be
> answered. So far what I (and I am sure others) have not heard is a
> strong case for changing the behavior, given that it is in line with a
> reasonable interpretation of the standards.
>
> >Given two strings of different in a comparison, most database systems
> >(by default) will blank pad the shorter string so that they are the same
> >length before performing the comparison.
> >
> >
> Understood, but what gain do you have in a case like this that might
> justify the effort that would go into making it, say, an initdb option?
> How often does this behavior cause problems?
>
> Best Wishes,
> Chris Travers
> Metatron Technology Consulting