From: | "Rod Taylor" <rbt(at)zort(dot)ca> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Basic DOMAIN Support |
Date: | 2002-03-08 04:44:13 |
Message-ID: | 09c801c1c65c$2c809640$b002000a@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
> "Rod Taylor" <rbt(at)zort(dot)ca> writes:
> > Changing ColLabel to ColId seems to have corrected the problem but
now
> > I'm completely confused as to how it works.
>
> Well, you don't really need to know anything about the parsing
algorithm
> to see that the way you had it was ambiguous. Consider input
> DEFAULT = foo
> If DEFAULT can be a ColLabel, then there are two valid parsings of
> this input: one in which foo is reduced to c_expr and one in which
> it's reduced to a typename. That ambiguity is what creates the
> shift/reduce conflict.
I see.. For some reason I convinced myself that each level was
intepreted by itself, if a match couldn't be found it would dig down
rule. That is, take the first matching depth it finds. Conflicts
were generated by 2 matches at the same deptch. In this case ColLabel
is a subrule, where DEFAULT is a direct match to 'default'.
Makes alot more sense to pre-resolve the tree when I think about it.
I'm used to working with interpreted languages where something like
that would kill a ton of CPU for a majority of cases, but when it's
compiled it only needs to be resolved once; of course.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-03-08 04:45:15 | Re: Small fix for _copyGrantStmt |
Previous Message | Rod Taylor | 2002-03-08 04:38:05 | Re: Basic DOMAIN Support |