Hi Kostja!
On 12 Jul 2007, at 13:02, Konstantin Osipov wrote:
> * Chad MILLER <cmiller@stripped> [07/07/12 19:03]:
>> Below is the list of changes that have just been committed into a
>> local
>> 5.1 repository of cmiller. When cmiller does a push these changes
>> will
>> be propagated to the main repository and, within 24 hours after the
>> push, to the public repository.
>> For information on how to access the public repository
>> see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
>>
>> ChangeSet@stripped, 2007-07-12 10:49:37-04:00,
>> cmiller@stripped +7 -0
>> Bug#27175: invalid colum attributes in create/alter table
>>
>> One could define columns with contradictory or duplicate attri-
>> butes. E.g. "NULL NOT NULL DEFAULT 'foo' DEFAULT 'bar' NULL NULL"
>>
>> Now, check that explicitly-set or -unset flags are never reset
>> in the same statement.
>>
>> include/mysql_com.h@stripped, 2007-07-12 10:49:34-04:00,
>> cmiller@stripped +3 -0
>> Add flags to assist with deteting contradiction and conflicts.
>>
>
> mysql_com.h is for network declarations, available both to the
> client library and the server.
Ah, agreed. These flags are indeed orthogonal to the others labeled
"Used in sql_yacc.yy".
>
>> + /**
>> + Mask of bits used in "type", to keep track of each bit which
>> has been
>> + explicitly set to 0 or 1. This allows to detect conflicts
>> between user
>> + options. Otherwise a user could specify contradictory
>> attributes as in
>> + "c int PRIMARY KEY NULL" .
>> + */
>> + ulong type_explicit;
>
> Why are all these in the main LEX?
> It seems that the problem may happen only when describing columns
> for CREATE or ALTER, so why not add these 'bits' to Create_field
> instead?
I don't have an objection to that, exactly. I was adding code in the
style it is already used.
Create_field doesn't presently have the logic about that
information. It's all in sql_parse.cc add_field_to_list(), which
gets called after we gather the definition for the new field. See
the field_spec rule in sql_yacc.yy ; there, I would rather define a
Create_field instance and move all that length, default_value,
charset, comment, et c. stuff into it as members. The
add_field_to_list parameters would have only two parameters that
mentions lex -- lex->thd, and a (Create_field*) lex->creating_field .
Does that sound worthwhile to you? (If so, I have to figure out how
to handle this, as I'm not supposed to spend time significantly
altering contributed patches.)
- chad
--
Chad Miller, Software Developer chad@stripped
MySQL Inc., www.mysql.com
Orlando, Florida, USA 13-20z, UTC-0400
Office: +1 408 213 6740 sip:6740@stripped
Attachment: [application/pgp-signature] This is a digitally signed message part PGP.sig
