Re: [HACKERS] Re: ALTER TABLE DROP COLUMN

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