Обсуждение: Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y'
> Update of /usr/local/cvsroot/pgsql/src/backend/parser > In directory hub.org:/tmp/cvs-serv80148/parser > > Modified Files: > gram.y > Log Message: > Repair recently-introduced error in makeIndexable for LIKE: > a non-leading % would be put into the >=/<= patterns. Also, repair > longstanding confusion about whether %% means a literal %%. The SQL92 > doesn't say any such thing, and textlike() knows that, but gram.y didn't. > > Houston, we have a problem. DoMatch has: case '%': /* %% is the same as % according to the SQL standard */ /* Advance pastall %'s */ while (*p == '%') Don't we want %% to be %? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <maillist@candle.pha.pa.us> writes: >> Repair recently-introduced error in makeIndexable for LIKE: >> a non-leading % would be put into the >=/<= patterns. Also, repair >> longstanding confusion about whether %% means a literal %%. The SQL92 >> doesn't say any such thing, and textlike() knows that, but gram.y didn't. > Houston, we have a problem. DoMatch has: > case '%': > /* %% is the same as % according to the SQL standard */ > /* Advance past all %'s */ > while (*p == '%') > Don't we want %% to be %? I looked at the spec, and this piece of code is right: there is nothing in the spec that says that %% means anything other than two string pattern matches (which of course has the same effect as one). So I made gram.y agree. It could be that people like Microsoft don't follow the spec... can anyone check this? regards, tom lane
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > >> Repair recently-introduced error in makeIndexable for LIKE: > >> a non-leading % would be put into the >=/<= patterns. Also, repair > >> longstanding confusion about whether %% means a literal %%. The SQL92 > >> doesn't say any such thing, and textlike() knows that, but gram.y didn't. > > > Houston, we have a problem. DoMatch has: > > > case '%': > > /* %% is the same as % according to the SQL standard */ > > /* Advance past all %'s */ > > while (*p == '%') > > > Don't we want %% to be %? > > I looked at the spec, and this piece of code is right: there is nothing > in the spec that says that %% means anything other than two string > pattern matches (which of course has the same effect as one). So I made > gram.y agree. > > It could be that people like Microsoft don't follow the spec... can > anyone check this? DoMatch, which implements LIKE clearly thinks %% is %, and I think our users think so too. I would not change it. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <maillist@candle.pha.pa.us> writes: > DoMatch, which implements LIKE clearly thinks %% is %, Careful: DoMatch thinks %% is a wildcard (ie, same as %), not literal %. It's hard to say what our users think. If you'd written %% it would indeed match a % --- but you'd have a problem with it matching other stuff too. This might or might not be partially masked by the range conditions inserted by the parser. (But how long have we been doing that?) regards, tom lane
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > > DoMatch, which implements LIKE clearly thinks %% is %, > > Careful: DoMatch thinks %% is a wildcard (ie, same as %), not literal %. > > It's hard to say what our users think. If you'd written %% it would > indeed match a % --- but you'd have a problem with it matching other > stuff too. This might or might not be partially masked by the range > conditions inserted by the parser. (But how long have we been doing > that?) Sorry. I see now. I was confused. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026