Re: [HACKERS] Modulo syntax

Поиск
Список
Период
Сортировка
От Thomas Lockhart
Тема Re: [HACKERS] Modulo syntax
Дата
Msg-id 36FBAE52.56C10B72@alumni.caltech.edu
обсуждение исходный текст
Ответ на Re: [HACKERS] Modulo syntax  (Bruce Momjian <maillist@candle.pha.pa.us>)
Ответы Re: [HACKERS] Modulo syntax  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список pgsql-hackers
> >    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.

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...

Unless we are going to solve this, I would suggest backing out the
change in gram.y.
                       - Tom


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: pg_parg system table is suffering from software rot
Следующее
От: jwieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] PostgreSQL LOGO (was: Developers Globe (FINAL))