MySQL Lists are EOL. Please join:

List:Internals« Previous MessageNext Message »
From:Russell E Glaue Date:June 11 2001 5:38pm
Subject:MySQL Model: Re: SELECT ... INTO grammar enhancement
View as plain text  
I don't mean to say what way is wrong or right, but if a feature is added
to MySQL, should not that feature comply with the design and strategy in
which MySQL is built upon?

If we are going to make the syntax similar to DB2, should we not do this
for the entire database and not just one feature?  Or lets edit the MySQL
design model to explicitly support the integration of IBM DB2 grammer.
To have the entire database compliant with a design model in which
everyone follows, and then have one (or just a few) feature(s) sticking
out differently seems a bit chaotic.  -- It's not a part of the model, yet
once in the code it will have to be supported for who knows how long.

It's just my opinion that to have standards and a design model is to make
sure the road in which technology is built on is straight and accurate and
less breakable. It may not seem like a big deal to waiver from this model
this one time for this feature, but if we are not strict and do not stick
to this model, then what about the next time, and the time after that?

Am I wrong?
What do other people think about this issue?

-RG


On Mon, 11 Jun 2001, Michael Widenius wrote:

> 
> Hi!
> 
> >>>>> "Charlie" == Charlie Root <antony@stripped> writes:
> 
> Charlie> Michael Widenius wrote:
>> 
>> Hi!
>> 
>> >>>>> "Antony" == Antony T Curtis <antony@stripped>
> writes:
>> 
Antony> Allows grammar such as
>> 
Antony> SELECT tote_seq_no INTO @seq
Antony> FROM toteq WHERE tote_no=@tote AND zone=@zone AND status="O"
Antony> ORDER BY tote_seq_no
Antony> LIMIT 1;
>> 
>> Thanks for the patch, but I wouldn't like to accept this in this form.
>> 
>> The right way to do this would be to do:
>> 
>> SET @SEQ= SELECT tote_seq_no INTO @seq FROM toteq WHERE tote_no=@tote
>> AND zone=@zone AND status="O" ORDER BY tote_seq_no LIMIT 1;
>> 
>> This is more natural, especially in 4.1 when we have sub selects.
>> 
>> Do you want to change this or should I do it?
>> 
>> Regards,
>> Monty
> 
> Charlie> The reason for the grammar as I wrote it is for grammar compatibility
> Charlie> with IBM DB2 7.1
> 
> Charlie> Except that DB2 uses ':' as the character to identify variables instead
> Charlie> of '@' but I can accept that difference ;)
> 
> Charlie> For the things that I am doing, I would like to have same and/or similar
> Charlie> grammar between DB2 and MySQL.
> 
> Charlie> (It means that I may not be using DB2 to it's full abilities, but that
> Charlie> doesn't concern me too much right now)
> 
> Charlie> ANTONY T CURTIS
> 
> It's ok, if we provide both versions :)
> 
> Regards,
> Monty
> 

+------------------------------------------------------------------+
 Russell E Glaue, Technologies Engineer & Integrator  russ@stripped
 Center for the Application of Information Technologies
 WIU, 101 Horrabin Hall, 1 University Circle, Macomb, IL 61455
 http://www.cait.org


Thread
query engine and parserManish Chakrabarti6 Jun
  • query engine and parserMichael Widenius7 Jun
  • Re: query engine and parserSasha Pachev7 Jun
  • SELECT ... INTO grammar enhancementAntony T Curtis8 Jun
    • SELECT ... INTO grammar enhancementMichael Widenius10 Jun
  • Re: SELECT ... INTO grammar enhancementAntony T Curtis8 Jun
  • Re: SELECT ... INTO grammar enhancementAntony T Curtis8 Jun
  • Re: SELECT ... INTO grammar enhancementPaul Cadach11 Jun
    • Re: SELECT ... INTO grammar enhancementMichael Widenius11 Jun
  • Re: SELECT ... INTO grammar enhancementCharlie Root11 Jun
    • Re: SELECT ... INTO grammar enhancementMichael Widenius11 Jun
      • MySQL Model: Re: SELECT ... INTO grammar enhancementRussell E Glaue11 Jun
        • Re: MySQL Model: Re: SELECT ... INTO grammar enhancementAntony T Curtis12 Jun
        • MySQL Model: Re: SELECT ... INTO grammar enhancementMichael Widenius12 Jun