picking the correct locale when doing initdb
on bugs Magnus wrote:
It's a matter of picking the correct locale when you initdb your database.
and he is PERFECTLY right. Getting the locale wrong while doing intidb can
really screw up ones day.
But: because of initdb being at the very beginning, it is a really tough
decision based on not a lot of information. I know, same problem appears in
"bigger" databases too.
On the same time my impression is that since PostgreSQL is totally easy to
install on win32 (ok, still need to understand what are user rights, and
have ntfs), lots of "first timers" are upgrading from My to Postgre.
What can we do to make their first steps with "encodings" and "locale"
easier?
Harald
--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Reinsburgstraße 202b
70197 Stuttgart
0173/9409607
-
PostgreSQL - supported by a community that does not put you on hold
On 3/16/06, Harald Armin Massa <haraldarminmassa@gmail.com> wrote:
on bugs Magnus wrote:
It's a matter of picking the correct locale when you initdb your
database.
and he is PERFECTLY right. Getting the locale wrong while doing intidb can
really screw up ones day.But: because of initdb being at the very beginning, it is a really tough
decision based on not a lot of information. I know, same problem appears in
"bigger" databases too.On the same time my impression is that since PostgreSQL is totally easy to
install on win32 (ok, still need to understand what are user rights, and
have ntfs), lots of "first timers" are upgrading from My to Postgre.What can we do to make their first steps with "encodings" and "locale"
easier?
Here's an idea: let's make the locale a table-level setting, settable at
table creation time so that it's concievable to use postgresql to build,
say, a turist information site supporting english, german, spanish and
italian at the same time.
Tomislav
"Tomi NA" <hefest@gmail.com> writes:
Here's an idea: let's make the locale a table-level setting, settable at
table creation time so that it's concievable to use postgresql to build,
say, a turist information site supporting english, german, spanish and
italian at the same time.
Which locale would you use to perform comparisons for table joins?
In any case having actually implemented multilingual sites I can't imagine one
locale per table being useful at all. You always end up wanting per column,
even per array element locales.
--
greg
On Thu, Mar 16, 2006 at 09:21:56PM -0500, Greg Stark wrote:
In any case having actually implemented multilingual sites I can't imagine one
locale per table being useful at all. You always end up wanting per column,
even per array element locales.
Exactly, in the SQL standard it's referred to an COLLATE and it has
fairly detailed rules about how to deal with cross-column comparisons.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
tool for doing 5% of the work and then sitting around waiting for someone
else to do the other 95% so you can sue them.