Opérateur (supérieur) de comparaison de chaine de caractère

Opérateur (supérieur) de comparaison de chaine de caractère

Post by bcar » Wed, 14 Mar 2012 20:08:23



Bonjour,

je suis tomb aujourd'hui sur un comportement pour le moins
trange de la part des oprateurs de comparaison (>, >=, < et <=)

j'utilise des base postgres en version 9.0.4 et 9.1.01

exemple de comportement inattendu
select '511' > '5.9'
=> false (pour ma part j'attendais true puisque '1' > '.')

j'ai essay select '511'::character varying > '5.9'::character varying
(je l'ai test pour toutes les expressions que je vais exprim ici
mais ?a ne change rien)

donc
select '5' > '.' => true  (OK)
select '51' > '5.' => true  (OK)
select '511' > '5.1' => true  (OK)
select '511' > '5.2' => false  (NOT OK)
select '511' > '5.9' => false  (NOT OK)
select '511.' > '5.9.' => false  (NOT OK)

le problme m'a saut aux yeux lors d'un
select '5.15--------09:07:02' > '5-----------17:35:00' => false (NOT OK)
(les 2 chaines font 20 caractres)
mais le plus fort c'est que
select '5.15--------09:07:02' > '5-----------08:35:00' => true (OK)
select '5.15--------09:07:02' > '5-----------10:35:00' => true (OK)
select '5.15--------09:07:02' > '5-----------14:35:00' => true (OK)
select '5.15--------09:07:02' > '5-----------15:35:00' => false (NOT OK)
select '5.15--------09:07:02' > '5-----------15:10:00' => false (NOT OK)
select '5.15--------09:07:02' > '5-----------15:09:00' => true (OK)

Pour info : (code ascii du '.' = 46, code ascii du '-' = 45)

j'ai utilis le point mais on peut utiliser d'autres caractres
(',', '-', '+', ' ',...)

Ceci n'est pas du tout le comportement de l'oprateur de comparaisons
des langages de programmations (std::string de C++ par exemple).

Si ce n'est pas un bug, quelqu'un pourrait-il m'expliquer le
comportement de l'oprateur de comparaison de chaine de
caractre sous postgres, ou m'indiquer si j'ai rat une
option quelconque

Ce comportement est extrmement gnant puisqu'il influe aussi
sur les tris, les fonction max, min...

Merci pour vos lumires.

 
 
 

Opérateur (supérieur) de comparaison de chaine de caractère

Post by bcar » Wed, 14 Mar 2012 21:57:31


Le 13/03/2012 12:08, bcar a crit :

> Bonjour,

> je suis tomb aujourd'hui sur un comportement pour le moins
> trange de la part des oprateurs de comparaison (>, >=, < et <=)

> j'utilise des base postgres en version 9.0.4 et 9.1.01

> exemple de comportement inattendu
> select '511' > '5.9'
> => false (pour ma part j'attendais true puisque '1' > '.')

> j'ai essay select '511'::character varying > '5.9'::character varying
> (je l'ai test pour toutes les expressions que je vais exprim ici
> mais ?a ne change rien)

> donc
> select '5' > '.' => true  (OK)
> select '51' > '5.' => true  (OK)
> select '511' > '5.1' => true  (OK)
> select '511' > '5.2' => false  (NOT OK)
> select '511' > '5.9' => false  (NOT OK)
> select '511.' > '5.9.' => false  (NOT OK)

> le problme m'a saut aux yeux lors d'un
> select '5.15--------09:07:02' > '5-----------17:35:00' => false (NOT OK)
> (les 2 chaines font 20 caractres)
> mais le plus fort c'est que
> select '5.15--------09:07:02' > '5-----------08:35:00' => true (OK)
> select '5.15--------09:07:02' > '5-----------10:35:00' => true (OK)
> select '5.15--------09:07:02' > '5-----------14:35:00' => true (OK)
> select '5.15--------09:07:02' > '5-----------15:35:00' => false (NOT OK)
> select '5.15--------09:07:02' > '5-----------15:10:00' => false (NOT OK)
> select '5.15--------09:07:02' > '5-----------15:09:00' => true (OK)

> Pour info : (code ascii du '.' = 46, code ascii du '-' = 45)

> j'ai utilis le point mais on peut utiliser d'autres caractres
> (',', '-', '+', ' ',...)

> Ceci n'est pas du tout le comportement de l'oprateur de comparaisons
> des langages de programmations (std::string de C++ par exemple).

> Si ce n'est pas un bug, quelqu'un pourrait-il m'expliquer le
> comportement de l'oprateur de comparaison de chaine de
> caractre sous postgres, ou m'indiquer si j'ai rat une
> option quelconque

> Ce comportement est extrmement gnant puisqu'il influe aussi
> sur les tris, les fonction max, min...

> Merci pour vos lumires.

Je commence m'auto-rpondre.
Apparement cela serait du un problme de locale
La base semble tre configure en
LC_COLLATE = 'fr_FR.UTF-8'
LC_CTYPE = 'fr_FR.UTF-8'
Au lieu de
LC_COLLATE = 'C'
LC_CTYPE = 'C'
si j'ai bien compris

 
 
 

Opérateur (supérieur) de comparaison de chaine de caractère

Post by Mladen Gogal » Fri, 16 Mar 2012 10:25:33



> Bonjour,

> je suis tomb aujourd'hui sur un comportement pour le moins trange de
> la part des oprateurs de comparaison (>, >=, < et <=)

Guten Morgen
Koennen Sie bitte auf Deutsch schreiben? Mein Francoezisch ist ziemlich
schlecht. Englisch auch ist gut, aber kein Francoezisch, bitte.

--
http://mgogala.byethost5.com

 
 
 

Opérateur (supérieur) de comparaison de chaine de caractère

Post by bcar » Fri, 16 Mar 2012 17:11:06


Le 15/03/2012 02:25, Mladen Gogala a crit :


>> Bonjour,

>> je suis tomb aujourd'hui sur un comportement pour le moins trange de
>> la part des oprateurs de comparaison (>, >=, < et <=)

> Guten Morgen
> Koennen Sie bitte auf Deutsch schreiben? Mein Francoezisch ist ziemlich
> schlecht. Englisch auch ist gut, aber kein Francoezisch, bitte.

Good morning,

Sorry about my french explanation.
There was no old news in my reader and i have forgotten that is an
english newsgroup.

What I was say may be summarized in:

On postgres 9.0.4 and 9.1.0 I have unexpected results like
select '5' > '.' => true  (OK)
select '51' > '5.' => true  (OK)
select '511' > '5.1' => true  (OK)
select '511' > '5.2' => false  (NOT OK)
select '511' > '5.9' => false  (NOT OK)
select '511.' > '5.9.' => false  (NOT OK)

But I have understant that is a problem of locale, the database is
installed on a Red Hat (maybe 5.)

I have find that the base is configured on

ENCODING = 'SQL_ASCII'
LC_COLLATE = 'fr_FR.UTF-8'
LC_CTYPE = 'fr_FR.UTF-8'

If I try with

ENCODING = 'LATIN1'
LC_COLLATE = 'C'
LC_CTYPE = 'C'

It works fine.

So now I don't know if the problem is from fr_FR.UTF-8 on RedHat,
deprecated SQL_ASCII on prostgres or another thing

 
 
 

Opérateur (supérieur) de comparaison de chaine de caractère

Post by Fredrik Jonso » Fri, 16 Mar 2012 21:46:17



>  On postgres 9.0.4 and 9.1.0 I have unexpected results like
>  select '5' > '.' => true  (OK)
>  select '51' > '5.' => true  (OK)
>  select '511' > '5.1' => true  (OK)
>  select '511' > '5.2' => false  (NOT OK)
>  select '511' > '5.9' => false  (NOT OK)
>  select '511.' > '5.9.' => false  (NOT OK)


This is only controlled by collation. The default collaction of a database
is controlled when you run initdb (LC_COLLATE). However, as of postgresql 9.1
you can change collation order on a per column or even per query basis.

http://www.postgresql.org/docs/9.1/static/collation.html

 select '5' > '.';
 select '51' > '5.';
 select '511' > '5.1';
 select '511' > '5.2' COLLATE "C";
 select '511' > '5.9' COLLATE "C";
 select '511.' > '5.9.' COLLATE "C";

--
Fredrik Jonson

 
 
 

Opérateur (supérieur) de comparaison de chaine de caractère

Post by Jasen Bett » Sat, 17 Mar 2012 19:49:11



> Le 15/03/2012 02:25, Mladen Gogala a crit :
> Sorry about my french explanation.
> There was no old news in my reader and i have forgotten that is an
> english newsgroup.
> On postgres 9.0.4 and 9.1.0 I have unexpected results like
> select '5' > '.' => true  (OK)
> select '51' > '5.' => true  (OK)
> select '511' > '5.1' => true  (OK)
> select '511' > '5.2' => false  (NOT OK)
> select '511' > '5.9' => false  (NOT OK)
> select '511.' > '5.9.' => false  (NOT OK)


it looks like you may want the extension debversion.

I don't know if this extension is easily available outside of
debian.

select '5'::debversion > '.'::debversion ; --> false
select '51'::debversion > '5.'::debversion ; --> true
select '511'::debversion > '5.1'::debversion ; --> true
select '511'::debversion > '5.2'::debversion ; --> true
select '511'::debversion > '5.9'::debversion ; --> true
select '511.'::debversion > '5.9.'::debversion ; --> true

  5.1 < 5.9 < 5.11 < 5.11.1 < 5.11.2

--
?? 100% natural


 
 
 

1. Problemas de velocidad de conexion en las ma?anas.

------=_NextPart_000_0000_01C5BEAF.5F4F1660
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hola , perd=F3n pero mi ingles no es muy bueno.

=20

Tengo el siguiente problema.

=20

Tengo una aplicaci=F3n que corre bien en lo general , pero en las =
ma=F1anas al
llegar los usuarios del sistema este se comporta muy

Lento al transferir unas im=E1genes de clientes. Pasados unos 10 o 20 =
minutos
de operaci=F3n el sistema va volviendo mas rapido

Hasta que alcanza la velocidad correcta y funciona r=E1pido.

=20

=20

Esto lo hace todas las ma=F1anas y despu=E9s ya esta bien. No logro =
entender por
que pueda darse esto si no hay procesos diferentes

A las 8 a.m. o a las 4 pm. Son los mismos pero se comporta de manera
diferente.

=20

Mi aplicaci=F3n es en vb.net , la versi=F3n del Server es 4.01 para =
Linux rh9.
mi red es a 100 mbps

=20

Lo que mas me sorprende es que despu=E9s de un periodo de calentamiento =
ya
funcione bien.

=20

He buscado por dos caminos : el wait_timeout por que en la noche no hace
nada el Server por mas de 8 horas y

Que probablemente el dns este mal , ya que la maquina que actua como dns =
no
resuelve muy r=E1pido.=20

=20

Por el lado del DNS no se si afecte que le ponga al mysql de mi Server =
que
no lo use a ver si as=ED jala mas r=E1pido, pero esto tampoco

Se a ciencia cierta como hacerlo .

=20

=20

Cualquier comentario lo agradecer=E9 de verdad.

=20

=20

=20

=20

=20

=20

=20

Miguel Angel Huerta Gonzal=E9z

------=_NextPart_000_0000_01C5BEAF.5F4F1660--

2. Import Data Files

3. PORTAL DE VíDEOS PARA PROFISSIONAIS DE EVENTOS!

4. cd text

5. Centro de Estética l 2 diárias Ilha Grande l Filé de Peixe na Lagoa l Chega de celulite no Recreio l Kit com 4 Lubrificantes

6. NTVDM CPU error message

7. Read DataBase Files? - Lecture de fichiers de base de données?

8. Problème avec ODBC Lotus NotesSql driver 2.05 (limitation de 254 caractères)

9. Email Marketing - Nueva Base de Mails Enero 2011 - 950.000.000 de Mails + Sotf Full Sin Limitaciones