A quick question on 9. SET STATEMENT var1=... FOR SET SESSION var=...
I thought about this one for a little bit in which you change the same
variable 2 times. This statement I know would execute as: it would
store the current variable, the SET SESSION would override the
temporary set but would return to the old setting at the end not the
one after the FOR. I am unsure if I should have coded for this to
change to the SET SESSION after the running of the function. This
would also be true if a stored procedure contained a SET SESSION that
had a SET STATEMENT on the outside of execute. I figured that this
would have been described in how the function works and not to do it.
I would believe that the same variable would not be changed in the
statement in 99.99% of the queries. This would be unless they wanted
to override the SET inside the procedure and return to original then
they would use a SET STATEMENT which may be useful in rare cases.
On Mon, Aug 10, 2009 at 12:53 AM, Sergei Golubchik<serg@stripped> wrote:
> Hi, Joseph!
>
> On Aug 09, Joseph Lukas wrote:
>> KEY ACCOMPLISHMENTS LAST WEEK
>> Finished most of test cases so far. I am unsure of other areas to
>> test. I have tested to make sure that the variable is set during the
>> statement execution and change back. I have tested with various other
>> statements. Some most likely to be used others more random and highly
>> unlikely just to vary it up. I have also tested each system variable
>> type in the various cases.
>
> good
>
>> KEY TASKS THAT STALLED LAST WEEK
>> Not sure if all testing is done.
>
> few comments to your statement_set.test :
>
> more functional tests please, that is, more tests to show that the value
> is set, like SET STATEMENT ... FOR SHOW VARIABLES or
> SET STATEMENT ... FOR SELECT @@variable. In particular, consider cases
> like
>
> 1. prepared statements. just like the one you already have
> but with SHOW VARIABLES or SELECT @@variable
> 2. prepared statements. SET STATEMENT ... FOR PREPARE and
> SET STATEMENT ... FOR EXECUTE. The first SET should not affect the
> output of SHOW VARIABLES, I suppose, the second - should.
> 3. prepared statements. A mix of 1 and 2: SET STATEMENT ... FOR EXECUTE
> and another SET STATEMENT inside the prepared statement. One test
> where two SETs modify the same variable, another - different
> variables.
> 4. stored routines. SET STATEMENT *inside* a stored procedure. Or two
> SET STATEMENT, on different statements.
> 5. stored procedure. SET STATEMENT ... FOR CALL ...
> 6. mix of 4 and 5, like in
> CREATE PROCEDURE p1 ... BEGIN
> SELECT @@var1, @@var2;
> SET STATEMENT var1=... FOR SELECT @@var1, @@var2;
> SELECT @@var1, @@var2;
> SET STATEMENT var2=... FOR SELECT @@var1, @@var2;
> SELECT @@var1, @@var2;
> END;
>
> SELECT @@var1, @@var2;
> SET STATEMENT var1=... FOR CALL p1()
> SELECT @@var1, @@var2;
> 7. compound statement:
> SET STATEMENT var1=... FOR BEGIN ... END
> 8. how it affects parsing:
>
> SET STATEMENT sql_mode='ansi' SELECT * FROM "t1"
> SET STATEMENT sql_mode='ansi' PREPARE stmt1 FROM 'SELECT * FROM "t1"'
>
> the first one is an error, I suppose, but the second is ok
>
> 9. SET STATEMENT var1=... FOR SET SESSION var=...
> 10. like 9 but in a stored procedure:
> CREATE PROCEDURE p1 ... BEGIN
> SELECT @@var1;
> SET SESSION var1=...;
> SELECT @@var1;
> END;
>
> SELECT @@var1;
> SET STATEMENT var1=... FOR CALL p1()
> SELECT @@var1;
>
> Just a few ideas (not all of them are mine) :)
>
>> TASKS IN THE UPCOMING WEEK
>> Documentation, documentation, documentation. I am unsure what
>> documentation is to be done. I am assuming the manual entry for how
>> to use the function and the MySQL help entry for how to use the
>> command properly. Is this the only types of documentation? What
>> other types of documentation is required? Where do I look to create
>> the documentation above as well? I tried to look through the
>> developer tutorials but found nothing on required documentation.
>> Please let me know.
>
> User-level documentation - for the manual, that is - shouldn't be
> difficult, the feature you've implemented is conceptually very easy to
> explain. And you don't need to do even that. We have a dedicated
> documentation team to write this for you, so all you *really* need to do
> is to explain the *feature* to them - and I think that the task
> description in worklog is good enough for that. If not - I'll handle
> that part, I'm not bound by a GSoC deadline :)
>
> Comments in the code, though, are all on you. I'll review your work - as
> a complete patch - this week, and tell you where more detailed comments
> are needed.
>
> Until that you can add more test cases (and fix bugs that will be
> discovered, if any :).
>
> Regards / Mit vielen Grüßen,
> Sergei
>
> --
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Sergei Golubchik
> <serg@stripped>
> / /|_/ / // /\ \/ /_/ / /__ Principal Software Engineer/Server Architect
> /_/ /_/\_, /___/\___\_\___/ Sun Microsystems GmbH, HRB München
> 161028
> <___/
> Sonnenallee 1, 85551 Kirchheim-Heimstetten
> Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
> Vorsitzender des Aufsichtsrates: Martin Häring
>
