Re: [HACKERS] Re: ALTER TABLE DROP COLUMN

At 01:43 AM 2/29/00 +0100, Jan Wieck wrote:

> ALL the FK triggers are delayed until after the entire
> statement (what's wrong for ON DELETE RESTRICT - but that's
> another story), or until the entire transaction (in deferred
> mode).

Kind of wrong, just so folks understand the semantics are right in
the sense that the right answer is given (pass or fail) - you need
a stopwatch to know that we're not doing what the SQL3 suggests
should be done (catch the foreign key errors before changes are made
and without incurring the cost of a rollback).

The current way we're doing it - identically to "NO ACTION" is
fine for compatability purposes, though later we'd like to implement
a smart ON DELETE RESTRICT because the efficiency considerations
that led to its inclusion in SQL3 are reasonable ones.

> I'm far too less familiar with our implementation of nbtree
> to tell whether it would be possible at all to delay unique
> checking until statement end or XACT commit. At least I
> assume it would require some similar technique of deferred
> queue.

Presumably you'd queue up per-row triggers just like for FK constraints
and insert into the unique index at that point.

I have no idea how many other things this would break, if any.

- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.