MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:Chad MILLER Date:July 13 2007 4:55pm
Subject:Re: bk commit into 5.1 tree (cmiller:1.2508) BUG#27175
View as plain text  
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
Thread
bk commit into 5.1 tree (cmiller:1.2508) BUG#27175Chad MILLER12 Jul
  • Re: bk commit into 5.1 tree (cmiller:1.2508) BUG#27175Konstantin Osipov12 Jul
    • Re: bk commit into 5.1 tree (cmiller:1.2508) BUG#27175Chad MILLER13 Jul