[GRASS5] sql expression weirdnesses

[Daniel Calvelo Aros]

From: Glynn Clements <glynn at gclements.plus.com>
Sent: Tue, 7 Jun 2005 04:39:41 +0100
>
> The SQL parser doesn't implement the normal precedence rules for
> arithmetic operators, so e.g.:
> 
> 	(ALT_DIST/2+ALT_DIST/2 < 500)
> 
> parses as:
> 
> 	((((ALT_DIST/2)+ALT_DIST)/2) < 500)
> 
> Also, it doesn't allow parentheses within arithmetic expressions,
>  only logical (boolean) expressions.

So the set of acceptable expressions is very stringent. I'd take a wild guess
that infix left-associative with no parenthesis is less expressive that
"normal" infix: how would you rewrite a/(b+c)?

> I don't have a copy of the SQL standard, but I'm pretty sure that 
> both of those are bugs.

Same here. SQL expressions of this kind are meant to be arithmetically intuitive.

> At a glance, I would guess that the y_expression rule at the bottom 
> of lib/db/sqlp/yac.y should be split into something like:
> 
> y_expression:
> 		y_product			{ $$ = $1; }
> 	|	y_expression '+' y_product {
> 		    $$ = sqpNewExpressionNode ( sqpOperatorCode("+"), $1, $3 );
> 		}
> 	|	y_expression '-' y_product {
> 		    $$ = sqpNewExpressionNode ( sqpOperatorCode("-"), $1, $3 );
> 		}
> 	;
> 
> y_product:
> 		y_atom				{ $$ = $1; }
> 	|	y_expression '*' y_atom {
> 		    $$ = sqpNewExpressionNode ( sqpOperatorCode("*"), $1, $3 );
> 		}
> 	|	y_expression '/' y_atom {
> 		    $$ = sqpNewExpressionNode ( sqpOperatorCode("/"), $1, $3 );
> 		}
> 	;
> 
> y_atom:
> 		y_value				{ $$ = $1; }
> 	|	y_column			{ $$ = $1; }
> 	|	'(' y_expression ')'		{ $$ = $2; }
> 	;
> 
> Also the ARITHMETICAL_OPERATOR token would need to be removed from
> lex.l and yac.y, as its current definition makes it impossible to
> treat / differently to + and -.
> 
> This gives * and / precedence of over + and -, forces
> left-associativity, and allows parenthesised expressions.

Thanks for looking into it. I feared it would be a parser bug. IMHO a serious
one... Well, time to dig back into yacc. Anybody feeling like doing it in my
not-fully-acquainted-with-dbmi place?

Daniel.