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