Re: 'a' == 'a '
| От | Josh Berkus |
|---|---|
| Тема | Re: 'a' == 'a ' |
| Дата | |
| Msg-id | 200510191706.15115.josh@agliodbs.com обсуждение исходный текст |
| Ответ на | Re: 'a' == 'a ' (Was: RE: [pgsql-advocacy] [GENERAL] Oracle buysInnobase) ("Dann Corbit" <DCorbit@connx.com>) |
| Ответы |
Re: [GENERAL] 'a' == 'a '
|
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: