On Sat, 2002-09-14 at 19:43, Tom Lane wrote:
> Hannu Krosing <hannu@tm.ee> writes:
> > This seems to be a problem that is of similar nature to our UNIQUE
> > constraints not working in all cases (depending on the _physical_ order
> > of tuples, which should never affect any user-visible behaviour).
>
> No, I don't see any similarity at all. The behavior Alvaro is unhappy
> with is perfectly deterministic and repeatable. He's basically saying
> that DROP should be forgiving of redundant DROP operations, so long as
> they are packaged into a single command.
> I don't really agree with that, but it doesn't seem related to the UNIQUE issues.
The similarity is in COMMAND vs. TRANCACTION level checks.
Both other databases I tested (Oracle and DB2) disallow commands that
violate unique even inside a transaction, but they both allow commands
that must have some point of internal violation _during_ any serial
execution of the command:
ie. for table
t(i int not null unique)
having values 1 and 2
the command
update t set i=2 where i=1;
is not allowed on either of then, even inside transaction, but both
update t set i=i+1;
and
update t set i=i-1;
are allowed.
> > The two DROP TABLE cases are not equivalent in the sense that the first
> > is _one_ command and the other is _two_ separate commands.
>
> As long as they are wrapped into a single transaction block, there is no
> difference.
Once we will be able to continue after errors it may become a
significant difference -
DROP TABLE a,b CASCADE;
COMMIT;
will leave the tables untouched whereas
DROP TABLE b CASCADE;
DROP TABLE a CASCADE;
COMMIT;
Will delete both tables but issue an error;
-----
Hannu
