On Thu, Aug 9, 2012 at 3:05 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > ... btw, I think there is another problem here, which is that > generate_wildcard_trgm will restart get_wildcard_part at the > same place that the second loop exits, which means it would > do the wrong thing if what it returns is a pointer to the > second char of an escape pair. Consider for instance > > foo\\%bar > > The first call of get_wildcard_part will correctly extract "foo", > but then return a pointer to the second backslash. So the second > call will think that the % is escaped, which it is not, leading to > a wrong decision about whether to pad "bar".
Good catch! > Probably a minimal fix for this could be made by backing up "endword" > one byte before returning it if in_escape is true when the second > loop exits. That would not scale up to preserving the state of > in_wildcard_meta, but since the second loop never advances past a > meta char, that's okay for the moment. Or what about extending get_wildcard_part() so that it accepts the pointer to in_escape as an argument? generate_wildcard_trgm() can know the last value of in_escape and specify it the next call of get_wildcard_part(). Looks very simple. Regards, -- Fujii Masao - Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
