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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2000-02-29 10:22:27 | Re: [HACKERS] Re: ALTER TABLE DROP COLUMN |
Previous Message | Jose Soares | 2000-02-29 08:34:59 | Re: [HACKERS] having and union in v7beta |