[postgres] Matchen op 'rare' tekens

[Verwijderd]

Ik heb nu al een halve dag zitten zoeken, maar ik vind maar niet de goede definitie van het probleem waar ik mee zit:

Ik wil dat queries die bv. een SELECT doen op een veld genaamd 'schoolnaam', dat waarden als 'brëk' ook matchen op de zoekstring 'brek'. Het oplossen in de business layer vind ik GEEN goede oplossing voor mn toepassing, het zou puur door het dbms moeten afgehandeld worden.

Ik ben er zeker van dat er een functie bestaat die dat matchen toe laat, maar ik slaag er niet in om deze te vinden...

Iemand die me hiermee kan helpen, of me een degelijk engelse term kan geven waaronder dit probleem valt ?

EDIT: In mysql werkt dit matchen gewoon standaard op een SELECT LIKE query

[ Voor 9% gewijzigd door Verwijderd op 22-04-2003 12:26 ]

[jochemd]

Verwijderd schreef op 22 april 2003 @ 12:24:
Ik wil dat queries die bv. een SELECT doen op een veld genaamd 'schoolnaam', dat waarden als 'brëk' ook matchen op de zoekstring 'brek'.

In welke locale heb je je initdb gedaan?

[Verwijderd]

jochemd schreef op 22 april 2003 @ 12:39:
[...]
In welke locale heb je je initdb gedaan?

SQL_ASCII

Is een standaard installatie van Debian stable (woody). Postgresql zelf is versie 7.2.1.

[jochemd]

SQL_ASCII is niet de locale, dat is de charset. Maar dat geeft al voor een deel aan waar het probleem zit, SQL_ASCII is niet geschikt voor het gebruik met extended characters. Ik zou maar eens in de handleiding gaan lezen over locales, charsets en collation. En de laatste versie van PostgreSQL is 7.3.2 (7.3.3 is onderweg).

[Verwijderd]

Eens de 7.3 installeren van unstable, want die support zo te zien het meegeven van een locale per database, en da's wat ik nodig heb.

http://www.postgresql.org...&idoc=1&file=charset.html
The LC_COLLATE and LC_CTYPE variables affect the sort order of indexes. Therefore, these values must be kept fixed for any particular database cluster, or indexes on text columns will become corrupt. PostgreSQL enforces this by recording the values of LC_COLLATE and LC_CTYPE that are seen by initdb. The server automatically adopts those two values when it is started; only the other LC_ categories can be set from the environment at server startup. In short, only one collation order can be used in a database cluster, and it is chosen at initdb time.

Tnx voor de help.

(wie zei daar slotje ?)

[Verwijderd]

En toch wil het niet werken...

Ik heb postgresql 7.3.2rc1-2 geinstalleerd op een debian unstable bak.
initdb is gedaan met de nl_NL locale:

postgres@linux:~$ /usr/lib/postgresql/bin/pg_controldata /var/lib/postgres/data/
...
LC_COLLATE: nl_NL
LC_CTYPE: nl_NL

De database zelf heeft als encoding SQL_ASCII (met UNICODE kon ik niet eens een insert doen van een string met het karakter ö).

Als ik nu deze tabel heb:

code:

CREATE TABLE info (
    id serial NOT NULL,
    info character varying NOT NULL
);
COPY info (id, info) FROM stdin;
1       brok
2       brök
\.

Dan geeft een "SELECT info FROM info WHERE info LIKE 'brok'" slechts 1 rij terug ipv allebei...

Werkt dit bij jou wel en doe ik dus nog steeds iets mis ?

[jochemd]

In nl_NL zijn brok en brök dacht ik niet het zelfde. Je moet wel een locale nemen waarin ze wel het zelfde zijn.

[Verwijderd]

Op 'joel' en 'joël' geeft hij ook geen match, en dat zou toch wel moeten denk ik.
Er is ook nog een UTF-8 versie van die locale, maar dat geeft hetzelfde resultaat.

Maar goed, eens op zoek naar de locale specificatie. Of naar nl_LIMBURGS