maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Sergey!

On Mar 24, Sergey Vojtovich wrote:
> > 
> > > > > - YEAR(2) is deprecated in 5.6, do we want to deprecate it too?
> > > > 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.
> > The fundamental design flaw - only the Field itself knows that it's
> > YEAR(2), no item knows it. So, as long as you use YEAR(2) in any
> > expression - it loses its magic powers:
> I see. So what should we do about it? We have to different opinions.

Monty said that the reason for introducing YEAR(2) was to use less
storage. I don't know if that's a valid argument today, but anyway.
The suggestion was to remove YEAR(2) and introduce YEAR1 (or TINYYEAR,
or keep YEAR(2), whatever) type. Which stores the year in one byte, as
the old YEAR(2). But Field converts it to 4-digit year on retrieval - in
all val_xxx methods. That is, SELECT will show it as 4-digit year, even
though it'll be stored only in one byte.

If we do it this way, new one-byte year field will have no magic
behavior and it'll reliably work in all cases.

> > > > > - NO_ENGINE_SUBSTITUTION is default mode in 5.6 now, do we want it
> > > > > be default too?
> > > I believe it is a good idea to make it default too.
> > Okay. Old idea of SQL_MODE always was that empty set is always the
> > default. I mean, all sql-mode values were selected this way (e.g.
> > NO_ENGINE_SUBSTITUTION vs. ALLOW_ENGINE_SUBSTITUTION).
> > 
> > But I agree, we cannot keep this forever...
> Hmm... we could probably keep this idea, change the meaning of empty
> set to implicitely include NO_ENGINE_SUBSTITUTION and add
> ALLOW_ENGINE_SUBSTITUTION.

Yes, Monty suggested that too.
I'm not sure it's a good idea, it basically turns NO_ENGINE_SUBSTITUTION
into a no-op. No matter whether it's set or not, engine substitution is
not allowed. Which is backward incompatible and will break applications
that rely on the engine substitution (e.g. replication with
transactional master and non-transactional slaves).

> As for the new defaults it came to be that they are well documented, so I
> won't have to dig the code:
> http://dev.mysql.com/doc/refman/5.6/en/server-default-changes.html

all changes of buffer sizes, etc are ok.
options that affect the behavior... I don't know if we can do it that
late, even though it's a compatibility with MySQL 5.6 fix.

Regards,
Sergei