On Sun, 12 Jun 2022 at 18:02, Matthew Wild <[email protected]> wrote: > Hi Dave, > > On Sun, 12 Jun 2022 at 13:19, Dave Cridland <[email protected]> wrote: > > > > Hey Matthew, > > > > Many thanks for this, and also many thanks for raising these on the list > first instead of quietly via the document author, and my apologies for a > slow response. > > Thanks for the eventual response - I'm in no particular rush for this. > I just see people moving ahead and implementing what I see as a > mistake for the ecosystem, and wanted to provide what I see as a > better path forwards. > > A large part of your response is based on the idea that I (and the > text I proposed) is advocating only an "exact substring search". That > was *not* the intention. In particular, Postgres has plainto_tsquery > which would absolutely satisfy the requirements for simple search. > Lucene and ElasticSearch also offer similar solutions that tokenize > the input terms without any syntax interpretation. I don't see any > barriers to efficient simple text searches (they happen all the time > across most online services daily). > > Ah! Then I did indeed misunderstand you.
> What I'm trying to prevent is leaking implementation-defined esoteric > syntax to end users. That at least one implementation is already > exposing Lucene's special query syntax via this XEP is enough to > convince me that simple searches are worth pushing for. > Right, exposing something like Lucene is clearly insane on many levels. I'm not convinced that exposing any sort of syntax is bad, though - allowing the kind of syntax that websearch_to_tsvector allows seems harmless. But if we're faced with people that genuinely think exposing a search language, rather than interpreting an end-user search string, is sensible then we have clearly lost anyway. > > I agree regarding the rest of your email(s). Searching against full > text indices is essential for any production service. Often these are > language-specific, which is what led me to add the language indication > in my proposal as well. > > Hopefully this clarifies my intentions with the proposed changes. It > would appear we're in agreement on the requirements for efficient > searches. > > Regards, > Matthew > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
