maria-developers team mailing list archive
Mailing list archive
Re: Intermediate status for test cases merge
On Tue, Mar 18, 2014 at 05:25:59PM +0100, Sergei Golubchik wrote:
> Hi, Sergey!
> On Mar 11, Sergey Vojtovich wrote:
> > Hi!
> > So far I processed 431 test cases from the main suite. Most of them are up to
> > date, a few merged without problems, a few tests fail (bugs reported), a few
> > need extra analysis.
> > There are a few items which I'd like to discuss:
> > - INSERT DELAYED is deprecated in 5.6, do we want to deprecate it too?
> Probably not, it's being used. Apparently, it's about as popular as GIS
> (if the feedback data are any indication).
> > - SHOW PROFILE is deprecated in 5.6, do we want to deprecate it too?
> I'm not sure. It's being used too, although less than INSERT DELAYED,
> but more than XML functions :)
> Perhaps we can deprecate it in 10.1 or rewrite to use P_S...
Ok, should I create jira task?
> > - YEAR(2) is deprecated in 5.6, do we want to deprecate it too?
> > Monty suggests that we shouldn't deprecate it. I find it Ok too.
> > Reasons for YEAR(2) deprecation are not obvious, relevant worklog is
> > private. Relevant revision comment says: "YEAR(2) is a subject to
> > deprecation since it has ill design."
> I'd deprecate it - I agree about "ill design", it has lots of gotchas
> that are literally impossible to fix. In some cases it seems to work,
> but it's enough to change the query slightly - and it won't.
OTOH it requires less storage, which is a pro. It looks well-defined, that
is 0-69 are 2000-2069 and 70-99 are 1970-1999. Though I can't judge the design.
Monty likes it. Should I create jira task?
> > - EXPLAIN gives NULL in Extra column in 5.6 (empty string in 10.0), do we want
> > behave similarly?
> I don't see why.
> > - Do we want to merge fix for
> > BUG#60269 - mysql should reject attempts to create system tables in incorrect
> > engine
> > http://bugs.mysql.com/bug.php?id=60269
> No. That was lp:790513 for us, and I've fixed it differently.
> We have a test for this - t/plugin_innodb.test
Ok, will disregard this fix.
> > - NO_ENGINE_SUBSTITUTION is default mode in 5.6 now, do we want it be default too?
> May be. What do you think?
I'd say these days storage engines have way too different semantics. E.g. if
user requests FEDERATED but gets MyISAM further queries will return unexpected
I believe it is a good idea to make it default too.
> > - 5.6 has many updates to default values, do we like to merge them too?
> What was chanaged?
A lot. I'd better prepare list and start another thread.
> What do you think?
I think most of these changes are worthy.