# Comportamiento inesperado en las búsquedas: cuando 'commands' no encuentra '/commands'

**URL:** <https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217>\
**Category:** Bug\
**Tags:** search\
**Created:** [6 Julio, 2024 04:27 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217 "2024-07-06T04:27:02Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**Author:** ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)\
**Post date:** [6 Febrero, 2025 04:10 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217/13 "2025-02-06T04:10:13Z")

</div>

> [@MarcP](#):
>
> Apenas puedo estar de acuerdo en que esto no es un error, sino un enfoque muy poco común para una decisión de índice de búsqueda.

Tenga en cuenta que, de hecho, así es como funciona el stemmer/tokenizador de postgres sql, tenemos algunas soluciones provisionales para casos extremos como las URL en las que puede resultar confuso, pero en general externalizamos muchas de estas cosas a pg.

Curiosamente, tuvimos un hack hace unos años para “indexación adicional en URL” que @tgxworld eliminó debido a la hinchazón del índice.

Supongo que lo que puedo decir es que sí, estamos pensando en este tipo de casos extremos en la búsqueda, pero nos cuesta mucho impulsar el hackeo del marco existente en pg fulltext.

---

_[View the full topic](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217)._