Обсуждение: 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