[MDEV-7387] [PATCH] Alter table xxx CHARACTER SET utf8, CONVERT TO CHARACTER SET latin1 should fail Created: 2014-12-28  Updated: 2022-05-23  Resolved: 2015-03-13

Status: Closed
Project: MariaDB Server
Component/s: Parser
Affects Version/s: 10.0.15
Fix Version/s: 10.0.18

Type: Bug Priority: Major
Reporter: Daniel Black Assignee: Alexander Barkov
Resolution: Fixed Votes: 0
Labels: None

Attachments: File MDEV-7041.diff     File alter.patch    
Issue Links:
Relates
relates to MDEV-27896 Wrong result upon `COLLATE latin1_bin... Closed

 Description   

Both these terms set the default_table_charset attribute internally so whenever used they should be the same value.

Alter table xxx CONVERT TO CHARACTER SET latin1, CHARACTER SET utf8 has protection mechanism that result in an error.

However Alter table xxx CHARACTER SET utf8, CONVERT TO CHARACTER SET latin1 will ignore the utf8 and just use the latin1 for the default charset and conversion.

How to repeat:
Alter table xxx CHARACTER SET utf8, CONVERT TO CHARACTER SET latin1

on any table.

The resting table will have DEFAULT CHARSET=latin1

Attached patch causes and error consistent with Alter table xxx CONVERT TO CHARACTER SET latin1, CHARACTER SET utf8

 Comments   
Comment by Elena Stepanova [ 2014-12-28 ]

Thanks.

I'm not quite certain that it's not the other way round, that is that
Alter table xxx CONVERT TO CHARACTER SET latin1, CHARACTER SET utf8 is supposed to return an error. Why exactly are the definitions conflicting? One can apply every clause separately, in any order. I also don't see in the manual anything that explains this limitation (maybe I just haven't found it though).

Anyway, assigning to bar, he will know for sure.

Comment by Daniel Black [ 2014-12-28 ]

> I'm not quite certain that it's not the other way round, that is that
Alter table xxx CONVERT TO CHARACTER SET latin1, CHARACTER SET utf8 is supposed to return an error.

it does.

Currently Alter table xxx CHARACTER SET utf8, CONVERT TO CHARACTER SET latin1
converts to latin1 and sets the default to latin1. the utf8 is ignored.

The order matters because the parser sets a state and this state is only checked in the [DEFAULT] CHARACTER SET part.

> Why exactly are the definitions conflicting?

Internally both CONVERT TO and CHARACTER SET set the default character set and use the same variable underneath to represent this. If this wasn't the case we could make CHARACTER SET set the default and CONVERT do the conversion to anything however at the moment its just an internal limitation.

> One can apply every clause separately, in any order.

Yes.

> I also don't see in the manual anything that explains this limitation.

limitation is that is if CONVERT TO and CHARACTER SET are both set they have to be the same character set.

Comment by Daniel Black [ 2015-03-11 ]

https://github.com/MariaDB/server/pull/22

Comment by Alexander Barkov [ 2015-03-12 ]

Hi Daniel! Thanks for the patch! It looks correct.

I extended it slightly, basically 3 very small things:

1. Collected similar code which used for both "CHARSET SET" and "CONVERT TO"
into a method HA_CREATE_INFO::check_conflicting_charset_declarations(),
to avoid code duplication.

2. Added handling of conflicting declarations in cases:
CHARACTER SET DEFAULT, CHARACTER SET utf8
CHARACTER SET utf8, CHARACTER SET DEFAULT
I realized that before this change the second specification was just silently ignored,
which was not good.

3. Then moved the rest of the code as methods to HA_CREATE_INFO.
It's nice to take advantage of this occasion to offload sql_yacc.yy

Please have a look.

Many thanks for your contribution!
This would certainly stay unfixed for many months otherwise.

Comment by Daniel Black [ 2015-03-12 ]

nice. can't see any faults and thanks for adding the test cases and extending the scope.

Comment by Alexander Barkov [ 2015-03-13 ]

Pushed into the 10.0 git branch

Generated at Thu Feb 08 07:19:12 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.