|From:||Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru>|
|To:||Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>|
|Cc:||Aleksandr Parfenov <a(dot)parfenov(at)postgrespro(dot)ru>, David Steele <david(at)pgmasters(dot)net>, Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: new function for tsquery creartion|
|Views:||Raw Message | Whole Thread | Download mbox|
> Patch 03 (the documentation) needed some proof-reading. I've attached
> a new version of that patch with some small suggested improvements.
Thanks, I'm definitely going to use this.
> Is there anything to_tsquery() can do that websearch_to_tsquery()
> Would it be OK to use user-supplied websearch strings?
> Ie can it produce a syntax error?
I believe that's the most important question. After a private discussion
with Theodor I came to a conclusion that the most beneficial outcome
would be to suppress all syntax errors and give user some result,
cutting all misused operators along the way. This requires some changes,
> Is there any way to write OR as a term (that's a valuable non-stopword
> in French)?
You could quote it like this: websearch_to_tsquery('"or"');
Moreover, it's still possible to use & and |.
> It seems like AROUND(x) should be documented also more generally for
> tsquery, but I see there is some discussion about how that should
Personally, I like <N, M> operator better. It would instantly deprecate
AROUND(N), which is why I'm going to drop it.
> By the way, not this patch's fault, but I noticed that commit
> f5f1355dc4d did this:
> - (errmsg("query contains only
> stopword(s) or doesn't contain lexeme(s), ignored")));
> + (errmsg("text-search query contains
> only stop words or doesn't contain lexemes, ignored")));
> But the old test still appears in an example in
Will fix this.
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
|Next Message||Tom Lane||2018-03-26 16:50:00||Re: [HACKERS] pg_serial early wraparound|
|Previous Message||Tom Lane||2018-03-26 16:34:26||Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility|