Hannu Krosing wrote:
> Jan Wieck wrote:
> >
> > Actually, a RESTRICT violation can potentially bypass
> > thousands of subsequent queries until COMMIT. Meaningless
> > from the transactional PoV, but from the application
> > programmers one (looking at the return code of a particular
> > statement) it isn't!
> ...
> > It'll be expensive, compared to current UNIQUE implementation
> > doing it on the fly during btree insert (doesn't it?). But
> > the only way I see.
>
> So currently we have ON UPDATE RESTRICT foreign keys :)
For foreign keys we actually have ON UPDATE/DELETE NO ACTION (plus SET NULL and SET DEFAULT). Only the
RESTRICT isn't fully SQL3. I just had an idea that might easily turn it to do the right thing.
For the UNIQUE constraint, it's totally wrong (and not related to FOREIGN KEY stuff at all). The UNIQUE
constraint isn't deferrable at all, and it looks for violations on a per row level, not on a per set level as it
should.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
