From: "Mark" <mark@zserve.com>
> It appears that the behavior of a bpchar compare with a string literal
> is not implicitly trimming the bpchar before the compare, which IMHO is
> incorrect behavior. Is my opinion valid? If so, how difficult of a fix
> would this be in terms of time and effort? Should I submit a bug report
> to another list, or is a developer receiving this? Is this a feature?
bpchar==char==fixed, space padded AFAIK which means correct behaviour
> This is an important issue for me, because I am converting a db from MS
> SQL to postgresql. The MS SQL database uses bpchar (or just char in MS
> SQL terms) because performance is slightly better; the compares
> automatically trim the blanks off of the char at compare time. I have
> over 150 tables to work with, and I would rather not have to change them
> from bpchar to varchar, not to mention the performance decrease this
> might incur.
Surely it's just a search & replace.
No noticable performance issues with char vs varchar that I've found.
> You might be thinking, 'just use trim(username) everywhere you compare'.
> Yes, that is a solution, but not a practical one in my case. If this is
> a bug, I don't want to hack around it: I'd rather wait for the fix.
> Varchars would incur performance penalties I want to try to avoid if at
> all possible.
Try some testing with varchar - I'm not sure you are going to suffer much.
- Richard Huxton