I just used the upper(text) function on a database which is utf8 encoded
and which has spanish text.
All of the regular characters were properly converted, except for
characters which had accents.
On Mon, Jul 26, 2010 at 3:03 PM, Benjamin Krajmalnik wrote:
> I just used the upper(text) function on a database which is utf8 encoded and
> which has spanish text.
>
> All of the regular characters were properly converted, except for characters
> which had accents.
What are your various LC_* var
CREATE DATABASE ishield
WITH OWNER = postgres
ENCODING = 'UTF8'
LC_COLLATE = 'C'
LC_CTYPE = 'C'
CONNECTION LIMIT = -1;
> -Original Message-
> From: Scott Marlowe [mailto:scott.marl...@gmail.com]
> Sent: Monday, July 26, 2010 3:17 PM
> To: Benjamin Krajmalnik
I'd try creating a db with en_US or even better whatever is spanish
encoding for lc_collate and see what happens.
On Mon, Jul 26, 2010 at 3:18 PM, Benjamin Krajmalnik wrote:
> CREATE DATABASE ishield
> WITH OWNER = postgres
> ENCODING = 'UTF8'
> LC_COLLATE = 'C'
> LC_CTYPE = 'C
Unfortunately, the database has to accept data in multiple languages, since it
is a SaaS offering.
It is not a big deal - I just found it interesting that it did not uppercase
the accented letters.
The reason I came across it is that I created a table of all the ISO countries.
I had found a NyS
On Mon, Jul 26, 2010 at 3:47 PM, Benjamin Krajmalnik wrote:
> Unfortunately, the database has to accept data in multiple languages, since
> it is a SaaS offering.
The encoding determines that, not the collation. UTF-8 allows you to
insert various languages in that encoding.
> It is not a big d
On Mon, Jul 26, 2010 at 3:51 PM, Scott Marlowe wrote:
> On Mon, Jul 26, 2010 at 3:47 PM, Benjamin Krajmalnik
> wrote:
>> Unfortunately, the database has to accept data in multiple languages, since
>> it is a SaaS offering.
>
> The encoding determines that, not the collation. UTF-8 allows you t
System info: Lancelot 1874-T dual Intel Xeon(Nehalem-DP) SATAII 24GB
RAM, CentOS release 5.4 (Final), postgresql-server-8.4.4-1PGDG
hi,
We installed a fresh version of postgresql-server-8.4.4-1 using RPMs
from PGDG. We are seeing the following errors, if the system trys to do
'anything' sort
On Mon, Jul 26, 2010 at 16:01, Irene Barg wrote:
>> 2010-07-26 11:33:33 MST system_admin metadataERROR: could not write block
>> 503414 of temporary file: No space le
>> ft on device
>> 2010-07-26 11:33:33 MST system_admin metadataHINT: Perhaps out of disk
>> space?
>> -bash-3.2$ df -h
>> Files
Alex Hunsaker writes:
> On Mon, Jul 26, 2010 at 16:01, Irene Barg wrote:
> 2010-07-26 11:33:33 MST system_admin metadataERROR: Â could not write block
> 503414 of temporary file: No space le
> ft on device
> 2010-07-26 11:33:33 MST system_admin metadataHINT: Â Perhaps out of disk
> space?
> Ok s
Excerpts from Benjamin Krajmalnik's message of lun jul 26 17:03:54 -0400 2010:
> I just used the upper(text) function on a database which is utf8 encoded
> and which has spanish text.
>
> All of the regular characters were properly converted, except for
> characters which had accents.
FWIW it wor
On Mon, Jul 26, 2010 at 8:09 PM, Alvaro Herrera
wrote:
> Excerpts from Benjamin Krajmalnik's message of lun jul 26 17:03:54 -0400 2010:
>> I just used the upper(text) function on a database which is utf8 encoded
>> and which has spanish text.
>>
>> All of the regular characters were properly conve
Excerpts from Scott Marlowe's message of lun jul 26 23:12:08 -0400 2010:
> On Mon, Jul 26, 2010 at 8:09 PM, Alvaro Herrera
> wrote:
> > I suspect that the problem is an incorrect client_encoding setting.
>
> Yeah, OP had set lc_collate to C under the mistaken impression that
> collation controll
13 matches
Mail list logo
