Das ist mehr eine Notiz für mich...

Als ich die Suche schrieb, war Postgres 9.6 oder 10 aktuell, und websearch_to_tsquery() noch nicht verfügbar.
Deshalb zerlege ich die Suchausdrücke von Hand in search_translate_query in etwas, das ich später to_tsquery füttere.
Das hat einige Vorteile: ich bekomme eine Wortliste (gut für die "oder meinten sie das da"-Funktion), ich kann gezielt in einzelnen Feldern suchen (Beschreibung, nicht Technik - oder umgekehrt).

Diese Suche in einzelnen Feldern wird nicht genutzt. Nicht mal von mir.
Die Suche nach alternativen Suchbegriffen ist kompliziert, häßlich und prinzipiell nicht perfekt. Sie verwendet Stems, die nicht immer perfekt sind (Blüte -> Blut), und eine zusätzliche Wort-Tabelle, die sonst nicht gebraucht wird, und deren regelmäßiger Wiederaufbau theoretisch irgendwann für Störungen / Performanceprobleme sorgen könnte (praktisch wohl nicht - zumindest hat sie das noch nie).

Nächstes Problem: Das Umlauthandling. Es war gut gemeint, und tut meistens das, was es soll, aber es gibt ein paar pathologische Fälle ("y und z" => "y uend z", wodurch (a) die stopwort-Logik von postgres ausgehebelt wird, und (b) "und" falsch behandelt wird. Stört die Suche allerdings nicht, weil das anderswo wieder ausgebügelt wird, triggert aber die Suche nach alternativen Suchbegriffen.

Nächstes Problem: kaum jemand liest die Anweisungen. Die Syntax wird nicht verstanden und es wird auch selten versucht, sie zu nutzen.

Nächstes Problem: Die Suche nach Alternativen, über die search_words-Tabelle, ist weit langsamer als die eigentliche Suche - da ist ein Faktor 10.
Und das ist relevant, weil die Suchmaschinen die meisten Suchen triggern

Die andere Seite: websearch_to_tsquery hat eine sehr eingeschränkte Syntax:

• unquoted text: text not inside quote marks will be converted to terms separated by & operators, as if processed by plainto_tsquery.

• "quoted text": text inside quote marks will be converted to terms separated by <-> operators, as if processed by phraseto_tsquery.

• OR: the word “or” will be converted to the | operator.

• -: a dash will be converted to the ! operator.
  

"Und" ist nicht ausdrücklich… aber: `haubentaucher fisch` ist eine Undverknüpfung.
Was nicht geht: `(pfad|strasse) & (baum|allee)` -> `pfad or strasse baum or allee` => 'pfad' | 'strass' & 'baum' | 'alle' - wobei die Prezedenzen nicht klar sind.

Aber ist das wirklich wichtig?