Re: MySQL's "crashme" (was Re: Performance)

Hi,

Tom Lane:
> I'm just saying that it's unfair to downrate us when the problem is
> demonstrably in crashme itself and not in Postgres.
>
Right.

> <drop behavior> ::= CASCADE | RESTRICT
>
> What is *not* optional is a <drop behavior> keyword. Although we don't
> yet implement DROP COLUMN, our parser already has this statement in it
> --- and it follows the SQL92 grammar.
>
Ah, sorry, I apparently misparsed the BNF. (It was kind of late at
night...)

> No, pretty misleading I'd say. Since the crashme script does have a
> limit on max_buffer_size, it *will* run to completion if run on a
> machine with a sufficiently large per-process memory limit (and enough
> swap of course).

Hmm, I could add an explicit option to limit memory usage instead.
(Right now it's hardcoded in the test script.)

> >>>> date_zero=no # Supports 0000-00-00 dates
> >> Another test that only MySQL "passes".
> > ... and SOLID.
>
> Still doesn't mean it's a good idea ;-)
>
No argument from me...

> >>>> except=no # except
> It'd be appropriate to divide this into two tests, or at least relabel
> it.
>
Already done.

> Considering how much we got ragged on for not being perfectly compliant
> with SQL-spec handling of comments (up till 7.0 our parser didn't
> recognize "--" as a comment if it was embedded in a multicharacter
> operator --- but we knew that was a bug), I don't have a lot of sympathy
> for MySQL unilaterally redefining the spec here.

They do note this noncompliance with the SQL spec in their documentation,
along with a few others.

I'll clean this one up (adding a note about the noncompliance) a bit
more, after they incorporate my patch into the next version.

> Anyway, I am pleased to see you trying to clean up the mess.
> Good luck!
>
Thanks.

--
Matthias Urlichs | noris network GmbH | smurf(at)noris(dot)de | ICQ: 20193661
The quote was selected randomly. Really. | http://smurf.noris.de/
--
Mathematicians do it symmetrically.