Обсуждение: bpchar compares (was Re: Case Insensitive Queries)

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?

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.

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.

Thanks,

Mark

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