> > > I ran the query
> > > update producers SET cor_id = producer_id % 9 + 1;
> > > and found that result is eqiuvalent to
> > > update producers SET cor_id = producer_id % 9;
> > > I added parens:
> > > update producers SET cor_id = (producer_id % 9) + 1;
> > > and got what I needed.
> > Looks like a bug. We have associativity for +, -, * and /, but not %.
> > From gram.y:
> > %left '+' '-'
> > %left '*' '/'
> > I will add '%' to that.
>
> This will not fix the associativity problem, unless you *also* go
> through and add the explicit syntax *throughout* gram.y, as is
> currently done for '+', '-', etc.
>
> I'm pretty sure that we don't want to do this, since there are way too
> many other operators which would need the same treatment.
I did this for %. I felt it was common enough and similar to / that
people should expect it to have / associativity. I did not play with
any other operators.
>
> The correct solution will be to identify the operator as a particular
> class in scan.l, include that class in the associativity declarations,
> and then handle that class in the body of gram.y. Sort of like we do
> for generic operators already, but with some discrimination between
> them. To be done right, we should look up the precedence in a db
> table, to allow new operators to participate in the scheme. In any
> case, gram.y will become more complex...
Yikes. Don't think we want to go there.
>
> Unless we are going to solve this, I would suggest backing out the
> change in gram.y.
I would like to keep % as a special case like /.
-- 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