Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Re: ALTER TABLE DROP COLUMN

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Jan Wieck <wieck(at)debis(dot)com>
Cc: Don Baccus <dhogaza(at)pacifier(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
Date: 2000-02-29 10:17:05
Message-ID: 38BB9CA1.5FFA3F1F@tm.ee (view raw or flat)
Thread:
Lists: pgsql-hackers
Jan Wieck wrote:
> 
>     Explanative  version  of "that other story".  But not exactly
>     correct IMHO. If following strictly SQL3 suggestions,  an  ON
>     DELETE  RESTRICT  action cannot be deferrable at all. Even if
>     the constraint itself is deferrable and is set explicitly  to
>     DEFERRED,  the check should be done immediately at ROW level.
>     That's the difference between "NO ACTION" and "RESTRICT".
> 
>     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 :)

-------------
Hannu

In response to

Responses

pgsql-hackers by date

Next:From: Jan WieckDate: 2000-02-29 10:22:27
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
Previous:From: Jose SoaresDate: 2000-02-29 08:34:59
Subject: Re: [HACKERS] having and union in v7beta

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group