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@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.