Re: [HACKERS] scanner/parser for FOREIGN KEY

Tom Lane wrote:

> wieck(at)debis(dot)com (Jan Wieck) writes:
> > we still need the enhancement of the scanner/parser combo to
> > enable FOREIGN KEY specification as column constraint (the
> > due to shift/reduce disabled NOT DEFERRABLE part).
> > IMHO this must be done before going into BETA. As discussed,
> > a little token lookup/queueing between lex and yacc can do
> > the trick. I'd like to add a slightly generic method for it,
> > so the lookahead function can be reused if we sometimes get
> > trapped again with a similar problem.
> > Do we have a consensus to implement it that way now?
>
> AFAIR that was the only concrete solution offered. I think Thomas
> wanted to look into whether he could tweak the grammar to avoid the
> problem without lookahead, but he hasn't produced any results ---
> and I misdoubt that a fix done that way will be any cleaner than
> inserting a lexer lookahead interface.

The solution, Thomas suggested, would work too. It will avoid
any portability issues by making analyze.c slightly
complexer, but that's already complex enough by juggling
around with multiple lists, so one more hack there doesn't
count.

> In short, it's fine by me but I dunno if Thomas has signed on yet.

I'm fine with either solution. IMHO it's just a MUST BE THERE
before going BETA, since it affects the syntax of the query
language.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #