Re: [GENERAL] encoding bug or feature?
Tom , folks
I've recreated the database with --locale=es_AR
keyword
and all works fine
thanks a lot.
best
MDC
--- Tom Lane <[EMAIL PROTECTED]> escribió:
> marcelo Cortez <[EMAIL PROTECTED]> writes:
> > testutf8=# \set
> > ...
> > ENCODING = 'UTF8'
> > HISTSIZE = '500'
> > testutf8=# select upper('ñ');
> > ERROR: invalid UTF-8 byte sequence detected near
> byte
> > 0xf1
> > testutf8=#
>
> You're telling the system that your client encoding
> is utf8, but
> it looks from here like you're using some LatinN
> encoding.
> Try "\encoding latin1" or whatever it is your
> keyboard is generating.
>
> regards, tom lane
>
___
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [GENERAL] encoding bug or feature?
marcelo Cortez <[EMAIL PROTECTED]> writes:
> testutf8=# \set
> ...
> ENCODING = 'UTF8'
> HISTSIZE = '500'
> testutf8=# select upper('ñ');
> ERROR: invalid UTF-8 byte sequence detected near byte
> 0xf1
> testutf8=#
You're telling the system that your client encoding is utf8, but
it looks from here like you're using some LatinN encoding.
Try "\encoding latin1" or whatever it is your keyboard is generating.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [GENERAL] encoding bug or feature?
Jorge
my test, i created one utf8 database but don´t work
ideas?
testutf8=# \set
VERSION = 'PostgreSQL 8.1.0 on i386-pc-linux-gnu,
compiled by GCC cc (GCC) 3.3.5
(Debian 1:3.3.5-13)'
AUTOCOMMIT = 'on'
VERBOSITY = 'default'
PROMPT1 = '%/%R%# '
PROMPT2 = '%/%R%# '
PROMPT3 = '>> '
DBNAME = 'testutf8'
USER = 'marcelo'
HOST = '/var/run/sume'
PORT = '5432'
ENCODING = 'UTF8'
HISTSIZE = '500'
testutf8=# select upper('ñ');
ERROR: invalid UTF-8 byte sequence detected near byte
0xf1
testutf8=#
ideas?
best regards
MDC
Esa persona especial te espera en Yahoo! Encuentros.
¡Dejate encontrar!
http://ar.encuentros.yahoo.com/
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [GENERAL] encoding bug or feature?
marcelo Cortez <[EMAIL PROTECTED]> writes: > Jorge > > > the postgreslq.conf say > > > lc_messages = 'es_AR' # locale for > system error message > # strings > lc_monetary = 'es_AR' # locale for > monetary formatting > lc_numeric = 'es_AR'# locale for > number formatting > lc_time = 'es_AR' # > locale for time formatting > > but the upper function fail for me. > what is your settings? > BTW the database is SQL_ASCII > > any pointer be appreciated > best regards I believe you didn't get my reply to your personal message... Here's its body again: My settings are all pt_BR.UTF-8. # These settings are initialized by initdb -- they might be changed lc_messages = 'pt_BR.UTF-8' # locale for system error message # strings lc_monetary = 'pt_BR.UTF-8' # locale for monetary formatting lc_numeric = 'pt_BR.UTF-8' # locale for number formatting lc_time = 'pt_BR.UTF-8' # locale for time formatting My database is also in UTF-8. test=# \set VERSION = 'PostgreSQL 8.1.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.1.0 (SUSE Linux)' AUTOCOMMIT = 'on' VERBOSITY = 'default' PROMPT1 = '%/%R%# ' PROMPT2 = '%/%R%# ' PROMPT3 = '>> ' DBNAME = 'test' USER = 'godoy' PORT = '5432' ENCODING = 'UTF8' HISTSIZE = '500' test=# Try creating a database with an encoding other than SQLASCII and see if it works as you expect. -- Jorge Godoy <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] encoding bug or feature?
Jorge the postgreslq.conf say lc_messages = 'es_AR' # locale for system error message # strings lc_monetary = 'es_AR' # locale for monetary formatting lc_numeric = 'es_AR'# locale for number formatting lc_time = 'es_AR' # locale for time formatting but the upper function fail for me. what is your settings? BTW the database is SQL_ASCII any pointer be appreciated best regards MDC --- Jorge Godoy <[EMAIL PROTECTED]> escribió: > marcelo Cortez <[EMAIL PROTECTED]> writes: > > > folks > > > > > > select ucase( 'ñ'); -> 'ñ' > > i want this statemen return 'Ñ' > > any ideas? > > test=# select upper( 'ñ'); > upper > --- > Ñ > (1 record) > > test=# > > > Maybe your locale settings are wrong... > > -- > Jorge Godoy <[EMAIL PROTECTED]> > > ---(end of > broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq > ___ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] encoding bug or feature?
marcelo Cortez <[EMAIL PROTECTED]> writes: > folks > > > select ucase( 'ñ'); -> 'ñ' > i want this statemen return 'Ñ' > any ideas? test=# select upper( 'ñ'); upper --- Ñ (1 record) test=# Maybe your locale settings are wrong... -- Jorge Godoy <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[GENERAL] encoding bug or feature?
folks select ucase( 'ñ'); -> 'ñ' i want this statemen return 'Ñ' any ideas? best regards mdc _ Horóscopos, Salud y belleza, Chistes, Consejos de amor: el contenido más divertido para tu celular está en Yahoo! Móvil. Obtenelo en http://movil.yahoo.com.ar ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
