Re: bpchar compares (was Re: Case Insensitive Queries)

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