Doc patch needed: encodings?

Josh Berkus wrote:

I've noticed in recent testing that current versions of both RedHat
and SuSE default to encodings of "en_US.UTF-8" in the US.
Presumably they do something corresponding in other countries.

I think this means that in the basic install-from-source
instructions, we need to warn people to compile with --locale='C'.

I think not.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter,

I think this means that in the basic install-from-source
instructions, we need to warn people to compile with --locale='C'.  

I think not.

Care to explain that? Why shouldn't we warn people?

Otherwise we're set for 12,000 e-mails to the SQL list on "why doesn't this
query use and index, it did on my old machine".

--
Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus wrote:

Otherwise we're set for 12,000 e-mails to the SQL list on "why
doesn't this query use and index, it did on my old machine".

Linux distributions have been shipping with non-C locale settings for a
long, long time, so that complaint would be invalid. And even back
then we figured that recommending that people turn locale off was not
an acceptable "solution".

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter,

Linux distributions have been shipping with non-C locale settings for a
long, long time, so that complaint would be invalid.

In US distributions it's a recent thing. The switch to non-C locales is a
recent thing; RH Enterprise 3.0, and SuSE 9.0. But I expect in Europe you've
been using non-C locales for a while.

I'd like to have an explanation of this somewhere else newbies are liable to
read it, *before* their first production "LIKE" query doesn't use an index.
Where would be appropriate?

And, for English speakers, what exactly is wrong with using 'C' locale instead
of the environment one?

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

On Monday 06 December 2004 13:39, Josh Berkus wrote:

I'd like to have an explanation of this somewhere else newbies are liable
to read it, *before* their first production "LIKE" query doesn't use an
index. Where would be appropriate?

It's buried in the faq -> http://www.postgresql.org/docs/faqs/FAQ.html#4.8

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Josh Berkus wrote:

In US distributions it's a recent thing. The switch to non-C
locales is a recent thing; RH Enterprise 3.0, and SuSE 9.0.

I have it on record that Red Hat has set a non-C locale by default at
least since Red Hat 6.1 as distributed in North America (aren't they
the same anyway?) in 1999. I know that because we had this exact
discussion back then.

I'd like to have an explanation of this somewhere else newbies are
liable to read it, *before* their first production "LIKE" query
doesn't use an index. Where would be appropriate?

Near the documentation of "LIKE".

And, for English speakers, what exactly is wrong with using 'C'
locale instead of the environment one?

It makes it difficult to write a r�sum�, to name one thing.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e@gmx.net> writes:

Josh Berkus wrote:

I'd like to have an explanation of this somewhere else newbies are
liable to read it, *before* their first production "LIKE" query
doesn't use an index. Where would be appropriate?

Near the documentation of "LIKE".

I think it would be fair to mention this somewhere near the discussion
of creating a database cluster, too. The existing documentation does
warn you that sort order may be affected by your choice, but there is
nothing anywhere near that section to suggest that LIKE performance
might be affected. A para in the "Locale Support" section (in
charset.sgml) would probably be appropriate, and maybe another word or
two in the place that link to it in runtime.sgml and ref/initdb.sgml.

regards, tom lane

I have applied the following patch to mention non-C locales affect LIKE.

---------------------------------------------------------------------------

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Josh Berkus wrote:

I'd like to have an explanation of this somewhere else newbies are
liable to read it, *before* their first production "LIKE" query
doesn't use an index. Where would be appropriate?

Near the documentation of "LIKE".

I think it would be fair to mention this somewhere near the discussion
of creating a database cluster, too. The existing documentation does
warn you that sort order may be affected by your choice, but there is
nothing anywhere near that section to suggest that LIKE performance
might be affected. A para in the "Locale Support" section (in
charset.sgml) would probably be appropriate, and maybe another word or
two in the place that link to it in runtime.sgml and ref/initdb.sgml.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

I have applied the following patch to mention non-C locales affect
LIKE.

I don't think it's accurate to say that there is a performance impact.
The only impact is that you need to create a different kind of index.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:

Bruce Momjian wrote:

I have applied the following patch to mention non-C locales affect
LIKE.

I don't think it's accurate to say that there is a performance impact.
The only impact is that you need to create a different kind of index.

Well, there is a performance impact to using the locale functions, and
you can't use ordinary indexes for LIKE, just special ones. Is there
better text I should use?

I used "performance impact" in the reference text to suggest there is an
issue and they might want to read the locale section.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073