-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix TSVECTOR trigger definitions for search #3798
Comments
@jborichevskiy thank you for bringing this to our attention. We will look into this issue. |
endpoint is |
resultant query: SELECT * WHERE disclosure.fec_fitem_sched_b.recipient_name_text @@ to_tsquery('o:*'); |
example data:
|
example of 12 from BELTRAMI COUNTY I-R from above:
|
To test--consider generating new.recipient_name_text := to_tsvector(
concat(regexp_replace(new.recipient_nm, '[^a-zA-Z0-9]', ' ', 'g')), ' ',
new.clean_recipient_cmte_id); [edit: add |
Occurrences of
|
updated |
|
@jborichevskiy I updated the issue title based on the applicability of this issue to other searchable text. We expect as part of the overall resolution, the reported issue for "o'hare" will also be resolved. |
Occurrences of Update from @jason-upchurch : all entries formerly in this section are now addressed in #3798 (comment) |
Adding test coverage for each table in #3798 (comment) |
@jason-upchurch we can see the fix was merged but seems like it wasn't deployed to production yet, right? Because the problem still exists in production. |
@leobuskin thanks for checking in! @jason Upchurch’s work is scheduled to be merged to production on 7/9. We need to re-populate all the data tables to use the new logic. You can the follow that work here, #3836. #3836 is scheduled to be merged to production on 8/6. |
@leobuskin @jborichevskiy cc @PaulClark2 @lbeaufort : There remain some side effects associated with restoring this function which will be resolved under #3836. Thank you again for reporting this issue, and please let us know if you have any problems with the above query. |
Searching for common names with apostrophes such as "o'hare" returns results for what seems to be all contributions containing "o" instead of the expected "o'hare".
Is there a correct way of escaping passed quotes when using the API (where the same issues seems to apply)?
The text was updated successfully, but these errors were encountered: