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_tnt...@mail.gmail.com)
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
