maria-developers team mailing list archive

[Sergey Vojtovich <svoj@xxxxxxxxxxx>]

Hi Sergei,

On Mon, Mar 24, 2014 at 10:13:05AM +0100, Sergei Golubchik wrote:
> 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.
Ok, then I assume this issue is known and doesn't need extra attention from
my side yet.

> 
> > > > > > - 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).
I see.

> 
> > 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.
Ok, I'll create a task then.

Thanks,
Sergey