Re: [HACKERS] FOREIGN KEY and shift/reduce
От | Thomas Lockhart |
---|---|
Тема | Re: [HACKERS] FOREIGN KEY and shift/reduce |
Дата | |
Msg-id | 385122AC.DD64A626@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] FOREIGN KEY and shift/reduce (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] FOREIGN KEY and shift/reduce
|
Список | pgsql-hackers |
> > If I allow the <constraint attributes> in column constraints, > > I get 2 shift/reduce conflicts. Seems the syntax interferes > > with NOT NULL. Actually I commented that part out, so the > > complete syntax is available only for table constraints, not > > on the column level. > Well, I'm not a guru, but I looked anyway. It's a mess. The problem > is that when NOT is the next token, the grammar doesn't know whether > the NOT is starting NOT NULL, which would be a new ColConstraintElem, > or starting NOT DEFERRABLE, which would be part of the current > ColConstraintElem. So it can't decide whether it's time to reduce > the current stack contents to a finished ColConstraintElem or not. > The only way to do that is to look ahead further than the NOT. > > In short, we no longer have an LR(1) grammar. Yipes. > > After a few minutes' thought, it seems that the least unclean way > to attack this problem is to hack up the lexer so that > "NOT<whitespace>NULL" is lexed as a single keyword. Assuming that > that's doable (I haven't tried, but I think it's possible), the > required changes in the grammar would be small. The shift/reduce > problem would go away, since we'd essentially have pushed the > required lookahead into the lexer. > > It's possible that making this change would even allow us to use > full a_expr rather than b_expr in DEFAULT expressions. I'm not > sure about it, but that'd be a nice side benefit if so. > > Does anyone see a better answer? This'd definitely be a Big Kluge > from the lexer's point of view, but I don't see an answer at the > grammar level. I'd like a chance to fix it at the grammar level. It involves mixing NOT DEFERRABLE and NOT NULL into the same clauses, but if I can work it out I'd rather isolate the Big Kluges in gram.y, which seems to collect that kind of stuff. scan.l is still fairly clean... - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
В списке pgsql-hackers по дате отправления: