From: | "Richard Huxton" <dev(at)archonet(dot)com> |
---|---|
To: | "Mark" <mark(at)zserve(dot)com>, <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: bpchar compares (was Re: Case Insensitive Queries) |
Date: | 2001-05-30 17:34:38 |
Message-ID: | 005701c0e92e$d2f1c000$1001a8c0@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
From: "Mark" <mark(at)zserve(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Sharmad Naik | 2001-05-30 17:44:38 | php-nuke |
Previous Message | Roy Souther | 2001-05-30 17:02:01 | SELECT * INTO TABLE is not working for me. |