Thread: Unary % operator is broken in current sources

Unary % operator is broken in current sources

From
Tom Lane
Date:
These used to work:

regression=> select %f.f1   FROM FLOAT8_TBL f;
ERROR:  parser: parse error at or near "%"
regression=> select f.f1 %  FROM FLOAT8_TBL f;
ERROR:  parser: parse error at or near "from"

This is causing the float8 regress test to fail.

I suspect this has to do with Bruce's recent hacking on operator
associativity.
        regards, tom lane


Re: [HACKERS] Unary % operator is broken in current sources

From
Bruce Momjian
Date:
> These used to work:
> 
> regression=> select %f.f1   FROM FLOAT8_TBL f;
> ERROR:  parser: parse error at or near "%"
> regression=> select f.f1 %  FROM FLOAT8_TBL f;
> ERROR:  parser: parse error at or near "from"
> 
> This is causing the float8 regress test to fail.
> 
> I suspect this has to do with Bruce's recent hacking on operator
> associativity.

I see.  I see the same problem with / and +:test=> select %f.f1   FROM FLOAT8_TBL f;ERROR:  parser: parse error at or
near"%"test=> select /f.f1   FROM FLOAT8_TBL f;ERROR:  parser: parse error at or near "/"test=> select +f.f1   FROM
FLOAT8_TBLf;ERROR:  parser: parse error at or near "+"
 

\do % shows:
test=> \do %op|left_arg|right_arg|result |description        --+--------+---------+-------+-------------------% |
|float8   |float8 |truncate to integer% |float8  |         |float8 |truncate to integer% |int2    |int2     |int2
|modulus           % |int2    |int4     |int4   |modulus            % |int4    |int2     |int4   |modulus            %
|int4   |int4     |int4   |modulus            % |numeric |numeric  |numeric|modulus            (7 rows)
 

OK, I made the change.  It works now with special entries for %4 and 4%
in the grammer, similar to our handling of -4:regression=> select %f.f1   FROM FLOAT8_TBL f;?column?
---------------------0                   -34                  -1004                -1.2345678901234e+2000
    (5 rows)
 

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


Re: [HACKERS] Unary % operator is broken in current sources

From
Tom Lane
Date:
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> OK, I made the change.  It works now with special entries for %4 and 4%
> in the grammer, similar to our handling of -4:

Hmm, is that an adequate solution?  Are you sure there are no other
operators like % ?
        regards, tom lane


Re: [HACKERS] Unary % operator is broken in current sources

From
Bruce Momjian
Date:
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > OK, I made the change.  It works now with special entries for %4 and 4%
> > in the grammer, similar to our handling of -4:
> 
> Hmm, is that an adequate solution?  Are you sure there are no other
> operators like % ?

Not sure.  I know I only changed % to have precedence like /.  No one is
complaining, and I think the problems are restricted to +,-,*,/, and %. 
Should I fix any of these other ones?

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


Re: [HACKERS] Unary % operator is broken in current sources

From
Tom Lane
Date:
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Not sure.  I know I only changed % to have precedence like /.  No one is
> complaining, and I think the problems are restricted to +,-,*,/, and %. 
> Should I fix any of these other ones?

Right now I think % is the only problem, since it's the only operator
that has all three syntaxes (infix, prefix, postfix):

regression=> select distinct p1.oprname, p1.oprkind, p2.oprkind from
regression-> pg_operator as p1, pg_operator as p2
regression-> where p1.oprname = p2.oprname and p1.oprkind < p2.oprkind;
oprname|oprkind|oprkind
-------+-------+-------
#      |b      |l
%      |b      |l
%      |b      |r
%      |l      |r
-      |b      |l
?-     |b      |l
?|     |b      |l
@      |b      |l
(8 rows)

Having both infix and prefix syntaxes doesn't seem to confuse the
parser --- at least, we have regress tests of both prefix @ and
infix @ (likewise #) and they're not complaining.  Probably you need
a postfix syntax plus one or both of the other syntaxes to yield an
ambiguity that will confuse the parser.  I haven't tried to track it
down in the grammar, however.

My concern with hacking in a special case for '%' in the grammar
is that we'll need to do it again anytime someone adds an operator
with the right set of syntaxes.  It'd be better to understand *why*
the parser is having a hard time with this all of a sudden, and fix it
without reference to any particular operator.  Postgres is supposed to
be extensible after all...
        regards, tom lane


Re: [HACKERS] Unary % operator is broken in current sources

From
Bruce Momjian
Date:
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > Not sure.  I know I only changed % to have precedence like /.  No one is
> > complaining, and I think the problems are restricted to +,-,*,/, and %. 
> > Should I fix any of these other ones?
> 
> Right now I think % is the only problem, since it's the only operator
> that has all three syntaxes (infix, prefix, postfix):
> 
> regression=> select distinct p1.oprname, p1.oprkind, p2.oprkind from
> regression-> pg_operator as p1, pg_operator as p2
> regression-> where p1.oprname = p2.oprname and p1.oprkind < p2.oprkind;
> oprname|oprkind|oprkind
> -------+-------+-------
> #      |b      |l
> %      |b      |l
> %      |b      |r
> %      |l      |r
> -      |b      |l
> ?-     |b      |l
> ?|     |b      |l
> @      |b      |l
> (8 rows)
> 
> Having both infix and prefix syntaxes doesn't seem to confuse the
> parser --- at least, we have regress tests of both prefix @ and
> infix @ (likewise #) and they're not complaining.  Probably you need
> a postfix syntax plus one or both of the other syntaxes to yield an
> ambiguity that will confuse the parser.  I haven't tried to track it
> down in the grammar, however.
> 
> My concern with hacking in a special case for '%' in the grammar
> is that we'll need to do it again anytime someone adds an operator
> with the right set of syntaxes.  It'd be better to understand *why*
> the parser is having a hard time with this all of a sudden, and fix it
> without reference to any particular operator.  Postgres is supposed to
> be extensible after all...

I can tell you what I think.  +,-,*,/,% have special precedence so */ is
done before +-.  This is causing infix/prefix to break.  When % did not
behave with precidence like /, it worked fine.

So, I would only have to add cases for +,-,/,*.   We already have "-"
prefix done for negative numbers.

Comments on how to proceed?

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


Re: [HACKERS] Unary % operator is broken in current sources

From
Tom Lane
Date:
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> So, I would only have to add cases for +,-,/,*.   We already have "-"
> prefix done for negative numbers.

> Comments on how to proceed?

Tom Lockhart probably knows this stuff better than anyone else.
I vote we put the issue on "hold" until he's caught up with his
email ;-)
        regards, tom lane