Hi Monty,
It's great to have this confimed!
And let Informix and Oracle know. :-)
Jan
P.S.
Sorry for my delayed reply.
Lots of work these days...
Michael Widenius wrote:
>
> Hi!
>
> Do you still remember this discussion:
>
> Jan> I know Informix a little bit.
> Jan> Their server is basically in two possible modes:
> Jan> * online: serving clients.
> Jan> * quiescent: checking and repairing dbspaces.
> Jan> When the server is brought up, it enters the quiescent mode
> Jan> and "mounts" all the dbspaces it should work with.
> Jan> Only when it's ready, it enters the online mode.
> Jan> If you pass an option to the server,
> Jan> it only does the quiescent part and then exits.
> Jan> This way, they could get rid of standalone utilities for the check &
> repair.
>
> Jan> I'm not saying MySQL should go this direction.
> Jan> After all, MySQL's data files are very different in nature from Informix's
> dbspaces
> Jan> (those can be raw devices or cooked files, but the structure is
> page-oriented,
> Jan> just like Oracle).
>
> I just asked a guy from the ANSI SQL standard committee about this.
>
> I mailed the following example to him and asked if it was according to
> the standard to accept the following rows WITHOUT any errors:
>
> -------
> create table crash_q (a int, b int, unique (a,b));
> insert into crash_q values (1,1);
> insert into crash_q values (1,null);
> insert into crash_q values (1,null);
> ----------
>
> His answer was:
>
> 'Your interpretation of the semantics of null values and unique constraints is
> correct. A null value in any uniqueness column will cause that row not to be
> considered a duplicate of any other row'
>
> It looks like Informix and Oracle are not following the standard in
> this case...
>
> Anyway, I have added a test for this in crash-me so that we can get
> some more information about this next time we run it.
>
> Regards,
> Monty
