Lists: | pgsql-hackers |
---|
From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | "Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | BETWEEN SYMMETRIC/ASYMMETRIC |
Date: | 2002-04-03 04:26:20 |
Message-ID: | GNELIHDDFBOCMGBFGEFOAEPBCBAA.chriskl@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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
From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | "Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BETWEEN SYMMETRIC/ASYMMETRIC |
Date: | 2002-04-03 04:31:30 |
Message-ID: | GNELIHDDFBOCMGBFGEFOEEPBCBAA.chriskl@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
*sigh*
I actually attached the diff this time...
Chris
> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)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(at)postgresql(dot)org)
>
Attachment | Content-Type | Size |
---|---|---|
between.txt | text/plain | 3.3 KB |
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | "Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BETWEEN SYMMETRIC/ASYMMETRIC |
Date: | 2002-04-03 05:19:39 |
Message-ID: | 7012.1017811179@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)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_expr
a_expr NOT BETWEEN b_expr AND b_expr
a_expr BETWEEN SYMMETRIC b_expr AND b_expr
a_expr NOT BETWEEN SYMMETRIC b_expr AND b_expr
a_expr BETWEEN ASYMMETRIC b_expr AND b_expr
a_expr NOT BETWEEN ASYMMETRIC b_expr AND b_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