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 '  (Chris Travers <chris@travelamericas.com>)
Список 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 по дате отправления:

Предыдущее
От: "Dann Corbit"
Дата:
Сообщение: Re: 'a' == 'a ' (Was: RE: [pgsql-advocacy] [GENERAL] Oracle buysInnobase)
Следующее
От: "Dann Corbit"
Дата:
Сообщение: Re: 'a' == 'a '