Re: Fuzzy substring searching with the pg_trgm extension

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Artur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fuzzy substring searching with the pg_trgm extension
Date: 2016-01-29 14:02:03
Message-ID: 56AB70DB.6030608@sigaev.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Sure. I attached two patches. But notice that pg_trgm.limit should be used with
> this command:
> SHOW "pg_trgm.limit";
> If you will use this command:
> SHOW pg_trgm.limit;
> you will get the error:
> ERROR: syntax error at or near "limit"
> LINE 1: SHOW pg_trgm.limit;
> ^
>
> This is because "limit" is keyword I think.

It's easy to fix in gram.y:
@@ -1499,7 +1499,7 @@ set_rest_more: /* Generic SET syntaxes: */
;

var_name: ColId { $$ = $1; }
- | var_name '.' ColId
+ | var_name '.' ColLabel
{ $$ = psprintf("%s.%s", $1, $3); }
;

ColId doesn't contain reserved_keyword, it's impossible to change initial part
of var_name to ColId because of a lot of conflicts in grammar but could be easy
changed for second part of var_name. It seems like improvement in any case but
sml_limit or similarity_limit or even similarity_treshold is more preferable
name than just simple limit. In future we could introduce more tresholds/limits.

Also, should get/set_limit emit a warning about deprecation?

Some notices about substring patch itself:
1 trgm2.data contains too much duplicates (like Barkala or Bakalan). Is it
really needed for testing?

2 I'm agree with Jeff Janes about <<-> and <->> operation. They are needed.
(http://www.postgresql.org/message-id/CAMkU=1zynKQfkR-J2_Uq8Lzp0uho8i+LEdFwGt77CzK_tNtN7g@mail.gmail.com)

--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2016-01-29 14:11:21 Re: Sequence Access Method WIP
Previous Message Tom Lane 2016-01-29 13:48:34 Re: Sequence Access Method WIP