Hallo,

Version: PostgreSQL 8.1.4 on i386-portbld-freebsd6.2

Encoding: komplett alles Latin9

Das Wort: außen, als Text in einer Datenbank (Spalte hat datentyp text)=
..

datenbank=3D# select spalte from datenbank where upper(spalte) like 'AUS%=
';
Ergebnis: (0 Zeilen)

Eigentlich erwarte ich da doch, dass er mir bei 'aus%' auch außen anzei=
gt.

Ist das ein Bug oder ein Feature?

Viele Grüße

Susanne

--
Susanne Ebrecht,
52066 Aachen, Germany


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

hi susanne,

> Encoding: komplett alles Latin9
>
> Das Wort: außen, als Text in einer Datenbank (Spalte hat datentyp tex=
t).
>
> datenbank=3D# select spalte from datenbank where upper(spalte) like 'AU=
S%';
> Ergebnis: (0 Zeilen)
>
> Eigentlich erwarte ich da doch, dass er mir bei 'aus%' auch außen anz=
eigt.
>
> Ist das ein Bug oder ein Feature?

also ich wuerde sagen:
außen codiert er bei "Latin9" als "61 75 df 65 6e"
und bei der suche nach like "AUS%" vergleicht er auf "41 55 53"
das problem duerfte also bei der codierung des "ß" liegen.

da "ß" also ein vollkommen anderes zeichen als "S" ist, findet like das=

nicht.

ich loese diese probleme bislang ueber eigene pl/pgsql-funktionen. was
auch kein problem darstellt, da like bei anderen encodings als "C"
sowieso nicht indexunterstuezt sucht.

wenn jemand eine bessere loesung kennt, freue ich mich aber jederzeit
ueber neue erkenntnisse ;-)

viele gruesse
ralf

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

http://archives.postgresql.org

Susanne Ebrecht wrote:
> Hallo,
>
> Version: PostgreSQL 8.1.4 on i386-portbld-freebsd6.2
>
> Encoding: komplett alles Latin9
>
> Das Wort: außen, als Text in einer Datenbank (Spalte hat datentyp tex=
t).
>
> datenbank=3D# select spalte from datenbank where upper(spalte) like 'AU=
S%';
> Ergebnis: (0 Zeilen)
>
> Eigentlich erwarte ich da doch, dass er mir bei 'aus%' auch außen
> anzeigt.
>
> Ist das ein Bug oder ein Feature?
Natürlich habe ich mich zu dem Thema jetzt schlau gemacht und ich muss
sagen, ich habe einen heiden Respekt vor den Jungs, die sich damit
auseinandersetzen müssen.
Ich würde sagen, es war verdammt clever von PostgreSQL, dass Zeugs üb=
er
die locale abwickeln zu lassen und damit alles auf die
Betriebssystemler abzuschieben.
Das Thema Collation und utf8 ist ein Rattenschwanz ohne Ende.
Je tiefer man sich dort hineindenkt, um so wilder wird es.

Das Thema LIKE ist im SQL2003 aufgegriffen. Hier steht, dass like nur
soviele Zeichen verglichen werden wie vorgegeben. Heisst ist ein Zeichen
vorgegeben: like '%s%' wird auch nur nach einem Zeichen gesucht.

Daher greift hier auch nicht: ss=3Dß, weil ss sind ja zwei Zeichen,
während ß nur eines ist.

Susanne
--

Susanne Ebrecht,
52066 Aachen, Germany


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

http://archives.postgresql.org

Susanne Ebrecht hat geschrieben:
> Das Wort: außen, als Text in einer Datenbank (Spalte hat datentyp text).
>
> datenbank=3D# select spalte from datenbank where upper(spalte) like 'AUS%=
';
> Ergebnis: (0 Zeilen)
>
> Eigentlich erwarte ich da doch, dass er mir bei 'aus%' auch außen
> anzeigt.
>
> Ist das ein Bug oder ein Feature?

Wie gesagt, weder noch. Es ist halt so.

Vielleicht hilft in einigen Fällen ein Index und eine Funktion,
wie in diesem Beispiel:

test=3D> CREATE TABLE local (id serial PRIMARY KEY, val varchar(100));
CREATE TABLE
test=3D> INSERT INTO local (val) VALUES ('außen'), ('Ausschank'), ('Badeh=
ose');
INSERT 0 3
test=3D> CREATE FUNCTION local_f(text) RETURNS text LANGUAGE SQL IMMUTABLE
test-> AS $$SELECT lower(replace($1, 'ß', 'ss'))$$;
CREATE FUNCTION
test=3D> CREATE INDEX local_i ON LOCAL ((local_f(val)));
CREATE INDEX
test=3D> SELECT id, val FROM local WHERE local_f(val) LIKE 'aus%';
id | val
----+-----------
1 | außen
2 | Ausschank
(2 rows)

Läßt sich sicher erweitern!

Liebe Grüße,
Laurenz Albe

---------------------------(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

Ralf Burger wrote:
> was
> auch kein problem darstellt, da like bei anderen encodings als "C"
> sowieso nicht indexunterstuezt sucht.

Das halte ich aber für ein Gerücht. Vielmehr muss man nur den
*richtigen* Index setzen.

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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

nabend....


Peter Eisentraut schrieb:

> Ralf Burger wrote:
>
>> was
>> auch kein problem darstellt, da like bei anderen encodings als "C"
>> sowieso nicht indexunterstuezt sucht.
>
>
> Das halte ich aber für ein Gerücht. Vielmehr muss man nur den
> *richtigen* Index setzen.



ich hab jetzt nochmal nachgesehen, ob ich in 8.2 was ueberlesen hab.
aber da heisst es nach wie vor:

21.1.2. Behavior
The locale settings influence the following SQL features:
The ability to use indexes with LIKE clauses

The drawback of using locales other than C or POSIX in PostgreSQL is its
performance impact.
It slows character handling and prevents ordinary indexes from being
used by LIKE.
For this reason use locales only if you actually need them.


und wenn ich fuer die eventuelle verwendung von LIKE im query einen eigen=
en
index bauen muss, dann kommt es auf das gleiche raus, wie bei einer eigen=
en
pl/pgsql-function.


munter bleiben

ralf



---------------------------(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

Tach :~9

Ich glaube Peter spielt hier auf die passende Operator-Klasse (varchar_patt=
ern_ops bzw. text_pattern_ops) bei der Indexerstellung an.

Freundliche Grüße

Hakan Kocaman
Software-Development

digame.de GmbH
Richard-Byrd-Str. 4-8
50829 Köln

Tel.: +49 (0) 221 59 68 88 31
Fax: +49 (0) 221 59 68 88 98
Email: hakan.kocaman [at] digame.de

digame.de GmbH, Sitz der Gesellschaft: Köln, Handelsregister Köln, HRB =
32349
Geschäftsführung: Werner Klötsch, Marco de Gast


> -----Original Message-----
> From: pgsql-de-allgemein-owner [at] postgresql.org
> [mailto:pgsql-de-allgemein-owner [at] postgresql.org] On Behalf Of
> Ralf Burger
> Sent: Wednesday, May 02, 2007 10:24 PM
> To: Peter Eisentraut
> Cc: pgsql-de-allgemein [at] postgresql.org; Susanne Ebrecht
> Subject: [pgsql-de-allgemein] Re: [pgsql-de-allgemein]
> Problem mit der Sortierung von ß
>
> nabend....
>
>
> Peter Eisentraut schrieb:
>
> > Ralf Burger wrote:
> >
> >> was
> >> auch kein problem darstellt, da like bei anderen encodings als "C"
> >> sowieso nicht indexunterstuezt sucht.
> >
> >
> > Das halte ich aber für ein Gerücht. Vielmehr muss man nur den
> > *richtigen* Index setzen.
>
>
>
> ich hab jetzt nochmal nachgesehen, ob ich in 8.2 was ueberlesen hab.
> aber da heisst es nach wie vor:
>
> 21.1.2. Behavior
> The locale settings influence the following SQL features:
> The ability to use indexes with LIKE clauses
>
> The drawback of using locales other than C or POSIX in
> PostgreSQL is its
> performance impact.
> It slows character handling and prevents ordinary indexes from being
> used by LIKE.
> For this reason use locales only if you actually need them.
>
>
> und wenn ich fuer die eventuelle verwendung von LIKE im query
> einen eigenen
> index bauen muss, dann kommt es auf das gleiche raus, wie bei
> einer eigenen
> pl/pgsql-function.
>
>
> munter bleiben
>
> ralf
>
>
>
> ---------------------------(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
>

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend