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@xxxxxxxxxxxxxxxxxx> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
