Re: [HACKERS] FOREIGN KEY and shift/reduce

Thomas Lockhart wrote:

> > Bruce and I were talking about that last night. I think it could be
> > fixed by having the grammar treat
> > NOT DEFERRABLE
> > DEFERRABLE
> > INITIALLY IMMEDIATE
> > INITIALLY DEFERRED
> > as independent ColConstraintElem clauses, and then have a post-pass in
> > analyze.c that folds the flags into the preceding REFERENCES clause
> > (and complains if they don't appear right after a REFERENCES clause).
> > Pretty grotty, especially since you probably wouldn't want to do the
> > same thing for the other uses of these clauses in TableConstraint
> > and CreateTrigStmt ... but possibly cleaner than a lexer hack.
>
> analyze.c already does a grotty scan of the constraint clauses to push
> them out into the place Vadim's implementation expects them. We could
> identify the FK clauses and push them somewhere else, no problem
> (well, at least in principle ;).

I already added my own list of constraint clauses, where
foreign key ones are pushed out of the place until the index
stuff is done. Then the list is processed to add the trigger
statements to extras_after. It's enough of crippled code
there IMHO.

I like the other approach by wrapping around yylex() better.
We definitely insist on bison, and ship a prepared gram.c.
And a little test here showed, that having

static int kludge_yylex_wrapper(void);
#define yylex() kludge_yylex_wrapper()

in the top declarations section and defining

#undef yylex()
static int
kludge_yylex_wrapper(void)
{
return yylex();
}

at the very end of gram.y does a fine job, changing totally
nothing. So that's a perfect place to do exactly what Tom
suggested. I don't see any portability issues on that.

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) #