Re: COLLATE

Поиск
Список
Период
Сортировка
От Tomi NA
Тема Re: COLLATE
Дата
Msg-id d487eb8e0606071437p6422798cobb92dce54b7e68b4@mail.gmail.com
обсуждение исходный текст
Ответ на Re: COLLATE  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-general
On 6/7/06, Martijn van Oosterhout <kleptog@svana.org> wrote:

> Kind of all three, feeding off eachother. There's just not enough
> interest from any front to really get it moving. It's a fairly invasive
> change and without significant support and interest from somewhere,
> chances of completion let alone acceptance are pretty slim...

I don't get it. Maybe it's me or my environment.
About half of the work we do in my company is building webs on the
(excellent) eZ publish CMS. We routinely use MySQL even though the CMS
(at least declaratively) wolks on top of pgsql. We use MySQL on
inertia: it's the default db under eZ publish and it's easy to get
hosting.
On the other hand, I'd rather bite my hand off than use MySQL in some
other Internet apps (e-shop with a card payment interface and others).
Where am I going with all this?
Well, if you don't live in an english-speaking country, there's no
such thing as a single language web. Because of collation limitations,
however, postgresql would be the first to be crossed out on my list no
matter how good it is in all other respects.
I understand that the needed change is uncomfortably invasive, but not
beeing able to collate correctly is a show-stopping problem on a
professional site. The user opens a drop-down with several dozens of
cities, scrolls down a bit to where his city should be, dooesn't see
it because the collator places the weird letter all the way down at
the end of the list - and the user walks away. The other user can't
get info about the bus lines to the city or he doesn't buy a product
he want's because he doesn't see it where it's supposed to be. Another
user notices the error and dissregards the site as amateurish.
I understand I'm talking about a specific area of use, but isn't that
where the biggest growth in both the number of new applications as
well as the number of users is?
As it is, I'm happy to have a great RDBMS to build intranet, rich
client apps on - but that's about it.
I've used MySQL and MSSQL (unfortunately) and they both support
collation much better than pgsql. Not perfect, but much much better.
Maybe postgresql should try to set less ambitious goals and instead of
going for the holy grail of collation management (which is usualy
praiseworthy) try to provide at least db-level collation definitions
if table/row/cell level collation settings should proove too
challenging at the moment.

t.n.a.

В списке pgsql-general по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: COLLATE
Следующее
От: Tom Lane
Дата:
Сообщение: Re: COLLATE