From: | Where is Where <whisere(at)gmail(dot)com> |
---|---|
To: | Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, 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 |
Date: | 2019-07-21 23:28:50 |
Message-ID: | CAK3r-hMCsD5cHG++Fk9j7=EGEqyDEbfSeswrBnf2v4FHwGB8iA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello everyone, I am wondering if
AROUND(N) or <N, M> is still possible? I found this thread below and the
original post
https://www.postgresql.org/message-id/fe931111ff7e9ad79196486ada79e268%40postgrespro.ru
mentioned the proposed feature: 'New operator AROUND(N). It matches if the
distance between words(or maybe phrases) is less than or equal to N.'
currently in tsquery_phrase(query1 tsquery, query2 tsquery, distance
integer) the distaince is searching a fixed distance, is there way to
search maximum distance so the search returns query1 followed by query2 up
to a certain distance? like the AROUND(N) or <N, M> mentioned in the thread?
Thank you!
On Mon, Jul 22, 2019 at 9:13 AM Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru>
wrote:
> Hi everyone,
>
> I'd like to share some intermediate results. Here's what has changed:
>
>
> 1. OR operator is now case-insensitive. Moreover, trailing whitespace is
> no longer used to identify it:
>
> select websearch_to_tsquery('simple', 'abc or');
> websearch_to_tsquery
> ----------------------
> 'abc' & 'or'
> (1 row)
>
> select websearch_to_tsquery('simple', 'abc or(def)');
> websearch_to_tsquery
> ----------------------
> 'abc' | 'def'
> (1 row)
>
> select websearch_to_tsquery('simple', 'abc or!def');
> websearch_to_tsquery
> ----------------------
> 'abc' | 'def'
> (1 row)
>
>
> 2. AROUND(N) has been dropped. I hope that <N, M> operator will allow us
> to implement it with a few lines of code.
>
> 3. websearch_to_tsquery() now tolerates various syntax errors, for
> instance:
>
> Misused operators:
>
> 'abc &'
> '| abc'
> '<- def'
>
> Missing parentheses:
>
> 'abc & (def <-> (cat or rat'
>
> Other sorts of nonsense:
>
> 'abc &--|| def' => 'abc' & !!'def'
> 'abc:def' => 'abc':D & 'ef'
>
> This, however, doesn't mean that the result will always be adequate (who
> would have thought?). Overall, current implementation follows the GIGO
> principle. In theory, this would allow us to use user-supplied websearch
> strings (but see gotchas), even if they don't make much sense. Better
> then nothing, right?
>
> 4. A small refactoring: I've replaced all WAIT* macros with a enum for
> better debugging (names look much nicer in GDB). Hope this is
> acceptable.
>
> 5. Finally, I've added a few more comments and tests. I haven't checked
> the code coverage, though.
>
>
> A few gotchas:
>
> I haven't touched gettoken_tsvector() yet. As a result, the following
> queries produce errors:
>
> select websearch_to_tsquery('simple', '''');
> ERROR: syntax error in tsquery: "'"
>
> select websearch_to_tsquery('simple', '\');
> ERROR: there is no escaped character: "\"
>
> Maybe there's more. The question is: should we fix those, or it's fine
> as it is? I don't have a strong opinion about this.
>
> --
> Dmitry Ivanov
> Postgres Professional: http://www.postgrespro.com
> The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tsunakawa, Takayuki | 2019-07-22 00:47:28 | RE: Speed up transaction completion faster after many relations are accessed in a transaction |
Previous Message | David Rowley | 2019-07-21 22:35:27 | Re: Performance issue in foreign-key-aware join estimation |