FOREIGN KEY and shift/reduce

Hi,

I just committed a patch that turns on FOREIGN KEY. Thus,
REFERENCES used in CREATE TABLE now automatically creates the
appropriate constraint triggers. The implementation also
supports omitting the PK column definition, if the
corresponding columns should be the PRIMARY KEY of the
referenced table.

Also I completed some more of the generic trigger procs. For
MATCH FULL, the key existence check in PK table and these
actions are completed:

ON DELETE RESTRICT
ON DELETE CASCADE
ON UPDATE RESTRICT
ON UPDATE CASCADE

Still missing are the SET NULL and SET DEFAULT actions. The
former is easy and will follow soon, the latter looks tricky
if the implementation should support ALTER TABLE/DEFAULT
(what it IMHO must even if that ALTER TABLE isn't implemented
yet).

Anyway, I ran into some shift/reduce problem in the main
parser. The syntax according to SQL3 says

<constraint attributes> ::=
<constraint check time> [ [ NOT ] DEFERRABLE ]
| [ NOT ] DEFERRABLE [ <constraint check time> ]

<constraint check time> defines INITIALLY DEFERRED/IMMEDIATE
and defaults to IMMEDIATE.

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.

Could some yacc-guru please take a look at it?

Another interesting question is about inheritance. If a
REFERENCES constraint exists for a table, must another table,
inheriting this one, also get all the FK checks applied?

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