Dann,
> I think that whatever is done ought to be whatever the standard says.
> If I misinterpret the standard and PostgreSQL is doing it right, then
> that is fine. It is just that PostgreSQL is very counter-intuitive
> compared to other database systems that I have used in this one
> particular area. When I read the standard, it looked to me like
> PostgreSQL was not performing correctly. It is not unlikely that I read
> it wrong.
AFAIT, the standard says "implementation-specific". So we're standard.
The main cost for comparing trimmed values is performance; factoring an
rtrim into every comparison will add significant overhead to the already
CPU-locked process of, for example, creating indexes. We're looking for
ways to make the comparison operators lighter-weight, not heavier.
My general perspective on this is that if trailing blanks are a significant
hazard for your application, then trim them on data input. That requires
a *lot* less peformance overhead than doing it every time you compare
something.
Changing the behaviour would break backwards compatibility for some users.
For that matter, I've been subscribed to 8 PostgreSQL mailing lists since
1999, and this is the first time I can recall someone complaining about
this comparison behavior. So it's obviously not a widespread issue.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
