Re: Keep specialized query pairs, or use single more general but more complex one

2025-02-24 Thread Greg Sabino Mullane
On Mon, Feb 24, 2025 at 11:50 AM Dominique Devienne wrote: > We lookup whether there's a list of aliases for "Allison". If there are, > we send them in $3 as an array of string (e.g. ['All', 'Alli', ...], and the first one matching (thanks to > order by ord limit 1) is returned, if any. > Thank

Re: Keep specialized query pairs, or use single more general but more complex one

2025-02-24 Thread Dominique Devienne
On Mon, Feb 24, 2025 at 5:39 PM Greg Sabino Mullane wrote: > On Mon, Feb 24, 2025 at 4:46 AM Dominique Devienne > wrote: > >> But now we have a new requirement, for "fuzzy find". I.e. the client can >> ask for names >> which are not the exact in-DB names, but also aliases of those names. >> > ..

Re: Keep specialized query pairs, or use single more general but more complex one

2025-02-24 Thread Greg Sabino Mullane
On Mon, Feb 24, 2025 at 4:46 AM Dominique Devienne wrote: > But now we have a new requirement, for "fuzzy find". I.e. the client can > ask for names > which are not the exact in-DB names, but also aliases of those names. > ... > join unnest($3::text[]) with ordinality as aliases(name, ord) on c.

Re: Keep specialized query pairs, or use single more general but more complex one

2025-02-24 Thread Dominique Devienne
On Mon, Feb 24, 2025 at 3:51 PM Rob Sargent wrote: > API: > > * The first type never relies on fuzzy-find. > > Then have that app type use the simple, fast query. > I'm sorry, but that's neither helpful, nor relevant. --DD

Re: Keep specialized query pairs, or use single more general but more complex one

2025-02-24 Thread Rob Sargent
API: > * The first type never relies on fuzzy-find. Then have that app type use the simple, fast query. After all each app/code is making an explicit choice which yesterday was the same and tomorrow will be different.