Re: BETWEEN SYMMETRIC/ASYMMETRIC - Mailing list pgsql-hackers

From Tom Lane
Subject Re: BETWEEN SYMMETRIC/ASYMMETRIC
Date
Msg-id 7012.1017811179@sss.pgh.pa.us
Whole thread Raw
In response to BETWEEN SYMMETRIC/ASYMMETRIC  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
List pgsql-hackers
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> I was forced to put SYMMETRIC and ASYMMETRIC as reserved words - anything
> else seemed to give shift/reduce errors.  Is there anything I can do about
> that?

First thought is "don't try to be cute": forget the opt_asymmetry
clause, and instead spell out six productions
a_expr BETWEEN b_expr AND b_expra_expr NOT BETWEEN b_expr AND b_expra_expr BETWEEN SYMMETRIC b_expr AND b_expra_expr
NOTBETWEEN SYMMETRIC b_expr AND b_expra_expr BETWEEN ASYMMETRIC b_expr AND b_expra_expr NOT BETWEEN ASYMMETRIC b_expr
ANDb_expr
 

I have not checked that this will work, but usually the cure for parse
conflicts is to postpone the decision about which production applies.
The reason opt_asymmetry forces SYMMETRIC and ASYMMETRIC to become
reserved is that it requires a premature decision.  Given, say
    a_expr BETWEEN . SYMMETRIC

(where . means "where we are now" and SYMMETRIC is the current lookahead
token), an LR(1) parser *must* decide whether to reduce opt_asymmetry as
null, or to shift (implying that opt_asymmetry will be SYMMETRIC); it
has to make this choice before it can look beyond the SYMMETRIC token.
If SYMMETRIC might be a regular identifier then this is unresolvable
without more lookahead.  The six-production approach avoids this problem
by not requiring any shift/reduce decisions to be made until an entire
clause is available.

On second thought there may be no other way out.  Consider
foo BETWEEN SYMMETRIC - bar AND baz

Is SYMMETRIC a keyword (with "-" a prefix operator) or an identifier
(with "-" infix)?  This example makes me think that SYMMETRIC has to
become reserved.  But I wanted to point out that opt_asymmetry is
certainly a loser based on lookahead distance.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: Suggestions please: names for function cachability
Next
From: "Christopher Kings-Lynne"
Date:
Subject: Odd psql \i behaviour