Thread: BETWEEN SYMMETRIC/ASYMMETRIC
Hi All, As part of my ongoing quest to understand grammar files, I've been trying to implement BETWEEN SYMMETRIC/ASYMMETRIC. I've attached my current work. Can someone please look and tell me if I'm on the right track? With this patch, I get parse errors after BETWEEN if I go: SELECT 2 BETWEEN ASYMMETRIC 1 and 3; or SELECT 2 BETWEEN SYMMETRIC 1 and 3; So it doesn't seem to be working - I don't know why!! Don't look at the NOT BETWEEN stuff - I've not done it yet. 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? Chris
*sigh* I actually attached the diff this time... Chris > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Christopher > Kings-Lynne > Sent: Wednesday, 3 April 2002 12:26 PM > To: Hackers > Subject: [HACKERS] BETWEEN SYMMETRIC/ASYMMETRIC > > > Hi All, > > As part of my ongoing quest to understand grammar files, I've > been trying to > implement BETWEEN SYMMETRIC/ASYMMETRIC. > > I've attached my current work. Can someone please look and tell me if I'm > on the right track? With this patch, I get parse errors after > BETWEEN if I > go: > > SELECT 2 BETWEEN ASYMMETRIC 1 and 3; > > or > > SELECT 2 BETWEEN SYMMETRIC 1 and 3; > > So it doesn't seem to be working - I don't know why!! > > Don't look at the NOT BETWEEN stuff - I've not done it yet. > > 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? > > Chris > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
Attachment
"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