MySQL

The world's most popular open source database

Contact a MySQL Representative


  • MySQL.com
  • Developer Zone
  • Partners & Solutions
  • Customer Login
  • DevZone
  • Downloads
  • Documentation
  • Articles
  • Forums
  • Bugs
  • Forge
  • Blogs
 
  • Pages

    • About
    • Find and store the error return value in procedures or functions
  • Archives

    • June 2009
    • May 2009
    • April 2009
    • March 2009
    • February 2009
    • January 2009
    • December 2008
    • November 2008
    • October 2008
    • August 2008
    • July 2008
    • June 2008
    • May 2008
    • April 2008
  • Categories

    • MySQL 5.1 Features (3)
    • MySQL 5.4 New Features (2)
    • MySQL 6.0 New Features (5)
    • MySQL 6.x New Features (3)
    • News (8)
    • Personal Opinion (4)
    • Tiny Tweaks (10)
    • Uncategorized (15)



New Features In MySQL 6.x

Get the error return value in a variable

June 17th, 2009

One missing feature in our stored procedures and functions is that, if there’s an exception (error), you don’t know the error number or sqlstate or error message. The plan is there, of course, WL#2111 Stored Procedures: Implement GET DIAGNOSTICS but I haven’t ticked the architecture review box, and the best prospect for a volunteer is busy with performance schema work.

However, there is a way to get this in the next MySQL 5.4 (which is called mysql-next on launchpad and which will almost certainly become the September milestone). Use RESIGNAL.

For space reasons I’m only going to illustrate how to do this to find out the SQLSTATE. I think bright souls will realize it’s simple, though tedious, to extend this so you can get the error number too.

I found out what the possible SQLSTATE values are by looking in the manual (of all places, eh?) in section Appendix B.3. Server Error Codes and Messages. No doubt they’ll change, but not often and wildly.

I added 38 DECLARE EXIT HANDLER statements at the start of my procedure, just after the variable declarations. These lines are always the same for any procedure. They’re not executed unless an error happens so I don’t worry about speed. (Update: Roland Bouman’s blog says you should worry, I suppose it depends whether a large fixed parse cost is significant for your workload. Thanks for correcting, Roland.)


USE test
DROP PROCEDURE IF EXISTS p//
CREATE PROCEDURE p ()
BEGIN
DECLARE v INT;
DECLARE EXIT HANDLER FOR SQLSTATE '01000' BEGIN SET @e='01000'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '08004' BEGIN SET @e='08004'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '08S01' BEGIN SET @e='08S01'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '0A000' BEGIN SET @e='0A000'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '20000' BEGIN SET @e='20000'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '21000' BEGIN SET @e='21000'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '21S01' BEGIN SET @e='21S01'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '22001' BEGIN SET @e='22001'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '22003' BEGIN SET @e='22003'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '22004' BEGIN SET @e='22004'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '22007' BEGIN SET @e='22007'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '22008' BEGIN SET @e='22008'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '22012' BEGIN SET @e='22012'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '23000' BEGIN SET @e='23000'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '25000' BEGIN SET @e='25000'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '28000' BEGIN SET @e='28000'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '2F003' BEGIN SET @e='2F003'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '2F005' BEGIN SET @e='2F005'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '3D000' BEGIN SET @e='3D000'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '40001' BEGIN SET @e='40001'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '42000' BEGIN SET @e='42000'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '42S01' BEGIN SET @e='42S01'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '42S02' BEGIN SET @e='42S02'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '42S12' BEGIN SET @e='42S12'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '42S21' BEGIN SET @e='42S21'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '42S22' BEGIN SET @e='42S22'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE '70100' BEGIN SET @e='70100'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE 'HY000' BEGIN SET @e='HY000'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE 'HY001' BEGIN SET @e='HY001'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE 'XA100' BEGIN SET @e='XA100'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE 'XA102' BEGIN SET @e='XA102'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE 'XA106' BEGIN SET @e='XA106'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE 'XAE03' BEGIN SET @e='XAE03'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE 'XAE04' BEGIN SET @e='XAE04'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE 'XAE05' BEGIN SET @e='XAE05'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE 'XAE07' BEGIN SET @e='XAE07'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE 'XAE08' BEGIN SET @e='XAE08'; RESIGNAL; END;
DECLARE EXIT HANDLER FOR SQLSTATE 'XAE09' BEGIN SET @e='XAE09'; RESIGNAL; END;
DROP TABLE no_such_table;
END//

The final line, DROP TABLE, is an error I threw in there for illustration. Here’s what happens when I invoke the procedure:


mysql> call p()//
ERROR 1051 (42S02): Unknown table 'no_such_table'

Fine, but where’s the SQLSTATE? Well, if you paid attention, you know it’s in @e.


mysql> select @e//
+-------+
| @e |
+-------+
| 42S02 |
+-------+
1 row in set (0.00 sec)

Remember, you need the next release of 5.4 (”Azalea”) for this. My compliments as always to the architect (Peter Gulutzan) (me), the implementor (Marc Alff), the first code reviewer (Davi Arnaut), the second code reviewer (Sergei Golubchik), and the documenter (Paul DuBois).

Posted in MySQL 5.4 New Features | No Comments »

Soothsaying SQL Standardization Stuff

June 7th, 2009

In an earlier blog posting “SQL Standards, ANSI committees, and Sun”, I (Peter Gulutzan) talked about our prospects for joining the American committee charged with database standards, which we typically call “ANSI” although that’s not the formal name (and by the way the formal name is about to change, but I’ll chat about organization some other time).

Well, I’m now Sun’s official voting delegate to the committee. There are also three “alternate” delegates from other parts of Sun; I’ll loosely categorize them as advocates from our PostgreSQL-ophile and Java / Java DB interest groupings. Mostly my concern is the MySQL side of things.

The committee holds frequent meetings by telephone conference, and infrequent ones in personal get-togethers. I’ve just finished attending one of the lengthier meetings. I won’t discuss details or say how votes are going — our meetings are not public. But it’s always been harmless to inform the public about some things that might or might not be in a future version of the standard (”SQL:201x”). So, if we MySQLers act on some relevant feature in the next few years, you’ll know what we’ll take into account from the standard.

Enforced constraints.
A table foreign-key or check constraint may contain [NOT] ENFORCED. For example:
CREATE TABLE t2 (s1 INT, FOREIGN KEY f REFERENCES t1 (s1) NOT ENFORCED);
ALTER TABLE t2 ALTER CONSTRAINT f ENFORCED;
The DBMS ignores a not-enforced constraint. The default is ENFORCED. Currently MySQL has no equivalent, although it does have
SET @@foreign_key_checks = 0 | 1;
ALTER TABLE t2 DISABLE | ENABLE KEYS;
The words DISABLE and ENABLE are what Oracle uses. The words [NOT] ENFORCED are what DB2 uses.

Versioned tables.
Think of a bank-application table which has current balances and an associated history of deposits/withdrawals. We’d like to ask “what was the balance as of January 1″, which involves reversing transactions that took place since January 1. In other words, the DBMS should maintain and be aware of a history of changes. An example of syntax is:
CREATE TABLE t
(bank_balance DECIMAL(5,2),
sv_start TIMESTAMP GENERATED ALWAYS AS SYSTEM VERSION START,
sv_end TIMESTAMP GENERATED ALWAYS AS SYSTEM VERSION END
) WITH SYSTEM VERSIONING KEEP VERSIONS FOR 2 YEARS;
This might be good for audit trails. I don’t regard this as terribly close to Flashback Technology or version-enabled tables in Oracle; this is new to me.

General intervals.
The currrent standard INTERVAL data type is for datetime differences, for example “2 hours 15 minutes”. A more general interval would be applicable for spatial differences as well a datetime differences, and could have an anchor, for example “2 hours 15 minutes starting at noon on January 1″. Sometimes this sort of thing has been called a PERIOD. The effect on MySQL is small, we don’t even support INTERVAL yet (WL#831).

Named parameters
You can give a parameter a name, for example
CREATE PROCEDURE p (p1 INT, p2 INT) …
CALL p(p2 => 5, p1 => 10) …
I would have preferred to use AS for naming (as we do for SQL select lists), but Oracle and (since very recently) DB2 have decided to go with the new ‘=>’ token.

Defaults for parameters
You can use a parameter’s default value, for example
CREATE PROCEDURE p (p1 INT DEFAULT 1, p2 INT DEFAULT 2) …
CALL p (5, DEFAULT);
CALL p (5);
Presumably, if we keep the MySQL non-standard extension that allows CALL without parentheses, this will mean that
CALL p;
is the same as “CALL p(1,2);”.

Spatial changes
For the “Spatial” features, some changes will appear that we can mostly regard as bug fixes.

Posted in News | No Comments »

Performance Schema Facts

May 27th, 2009

I thought I was clear in earlier blog postings about Performance Schema, but I’ll have to write more firmly.

1. Performance Schema source code is available:
https://code.launchpad.net/~marc.alff/mysql-server/mysql-6.0-perfschema

2. Performance Schema has been in development for less than one year.

3. All Performance Schema worklog task descriptions are public on forge.mysql.com.

Posted in MySQL 6.x New Features | No Comments »

MySQL 5.4

May 20th, 2009

I suppose it looks odd that many of the “6.x” features I’ve blogged about are now “5.4″ features. Sorry about the surprise. In mitigation I observe that this means some things are now scheduled a bit quicker, and some are a lot better than expected. Sometimes it’s hard to know till tests are in.

The current server 5.4 download is here:
http://dev.mysql.com/downloads/mysql/5.4.html.
It does not have all the features yet that we have announced as 5.4.

The features in the current 5.4 download are:

* Scalability, that is, it works faster if you add cores or processors.
A lot of the work for this happened outside the MySQL group per se, it’s lovely to have bunches of performance experts from elsewhere in Sun Microsystems, also known as Sun Classic, doing the tweaks for us. Tests show that 5.4 is faster than any variant, whether genuine MySQL or not.

There’s a slideshow, a blog from a Sun Classic employee, a blog from an old-time MySQL employee, and even a reference manual with sections “Changes in MySQL 5.4.0″ and “What Is New in MySQL 5.4″.

Large customers are trying out the beta with (as I understand) happiness. Tomorrow (May 21 2009) there will be a web seminar (”webinar”) on the subject, see http://www.mysql.com/news-and-events/web-seminars/display-343.html.

* DTrace. [sic -- with a capital T!]
The worklog task description “Improved DTrace support in server” (WL#4541) explains that this is about adding instrumentation in the SQL code for routines that aren’t system calls (system calls are handled without us having to add instrumentation). The WL#4541 description is out of date, and so is the manual at the time I’m writing this, so expect the list of instrumentation points to be better than what’s documented.

The features that are already pushed into 6.0, and therefore almost certain to be in 5.4, are:

* Things that make it go faster.
Well, this has been called a “performance release”, so the scalability improvements get coupled with reduced locking / mutex contention (WL#3262 WL#3561 WL#3726 WL#4284) , subquery semijoins and materializations (WL#1110 WL#2980 WL#3751 WL#3985), batch/range joining (WL#2475 WL#2771 WL#4424).

* Things which make programmers’ lives easier.
In this category I put SIGNAL and RESIGNAL (WL#2110 WL#2265), INFORMATION_SCHEMA addition (WL#2822 for thefirst time in public!, and the PARAMETERS view), replication additions, character-set additions (WL#4164 WL#3759) and XML additions (WL#1397).

The features that are not already pushed into 6.0, but which I personally expect have a good chance
of going to 5.4 (we’ll know by the end of June), are:
Performance Schema (WL#2360 WL#4678), Globalization (WL#1349 WL#3764 WL#3997 WL#4642), error messages (WL#751), number-to-string conversions (WL#2649), GIS (WL#1326 WL#2377 ), and partitioning (WL#4444 WL#4571).

There’s also a bit of refactoring work going on in mysys.
And there are bug fixes, including Bug#989.

I decided not to reference worklog tasks that are private, so the above list has a few gaps.

The Date

The goal is that 5.4 will be GA in December 2009. The date is earlier than we thought of for 6.0. I think it’ll probably make some people happy.

Posted in MySQL 5.4 New Features | 2 Comments »

MySQL User Conference Presentations

May 1st, 2009

From the MySQL User Conference in Santa Clara.

Konstantin Osipov + Peter Gulutzan’s presentation, “New Foreign Keys in 6.1″, is now available as an odp (Open Office presentation slides) file here. Nobody stomped out in a rage. One attendee said it’s a great development, he’s been waiting for years to see multi-storage-engine foreign keys. Another asked whether the feature would be in Drizzle, and Peter didn’t have the answer at the time, but later he asked a Drizzle worker and heard it’s improbable.

Peter heard a sideshow presenter suggest that the MySQL / DB2 storage engine was a surprise. The person didn’t allow time for questions or comments, but here’s a belated note that we sent out the first press release two years ago, here.

Alexander Barkov + Peter Gulutzan’s BoF, about character sets, got only a few non-Sun attendees. The main concerns were not about new features, but about how to upgrade from old versions, or how to convert to UTF8. Peter made a foolish statement about stripping accents, for which apologies are in order, but it’s okay because nobody believed him at the time.

After the conference Peter, as if to remove all doubts re his foolishness, decided to walk around the adjacent communities of Milpitas and San Jose. Subsequent checking on Google Maps reveals that was a 25-mile stroll in the sun, so if you saw him later red-faced and limping, here’s hoping you didn’t get the wrong impression.

The rest of this blog post is the sheet that Konstantin Osipov and Peter Gulutzan used for the MySQL Camp demo, “MySQL 6.1 Test Drive”. Somebody was recording it; if you find the recording on the web, please send a comment. It looks better if you see the results, so come watch next time they demo.

Peter Gulutzan and Konstantin Osipov
Sun Microsystems

"This is a live nothing-behind-the-curtain demonstration
of features that actually work, in pre-alpha or alpha or
beta versions of MySQL including MySQL 6.0, 6.1, and future."

After each demonstration, there is a chance to ask
one or two questions. We will type more statements on request.

======================================================
Feature = Foreign keys / all storage engines (WL#148)
Demonstrator = Konstantin
Version = mysql-6.1-fk
Sample Statement text =
quit
/data1/mysql-6.1-fk.sh
DROP TABLE IF EXISTS t1,t2;
CREATE TABLE t1
 (s1 INT UNIQUE NOT NULL)
 ENGINE=FALCON;                /* Falcon + foreign key! */
CREATE TABLE t2
 (s1 INT DEFAULT 5 REFERENCES t1(s1)/* Legal Syntax at last! */
 ON UPDATE SET DEFAULT)
 ENGINE=FALCON;
CREATE TRIGGER t2_au AFTER UPDATE ON t2
 FOR EACH ROW SET @a='trigger happened';
INSERT INTO t1 VALUES (1),(5);
INSERT INTO t2 VALUES (2);     /* Won't work! */
INSERT INTO t2 VALUES (1);
UPDATE t1 SET s1 = 2 WHERE s1 = 1; /* Cascades! */
SELECT *,@a FROM t2;           /* Shows cascading worked! */
=======================================================
Feature = Supplementary Unicode Characters (WL#1213)
Demonstrator = Peter
Version = 6.0
Sample Statement text =
quit
/data1/mysql-6.0.sh
DROP TABLE IF EXISTS t;
SET NAMES UTF8;
CREATE TABLE t
  (s1 VARCHAR(5) CHARACTER SET UTF32); /* new character set! */
INSERT INTO t VALUES (0x000204d7);     /* rare cjk! */
INSERT INTO t VALUES (0x000100cc);     /* linear b! */
INSERT INTO t VALUES (0x00010400);     /* deseret! */
SELECT * FROM t;                       /* Visible with this font! */
=======================================================
Feature = Retrievable OUT parameters
Demonstrator = Konstantin
Version = 6.0
Sample Statement text =
quit
/data1/mysql-6.0.sh
DROP PROCEDURE IF EXISTS p1;
DELIMITER //
CREATE PROCEDURE p1(OUT v1 INT, OUT v2 CHAR(32))
BEGIN
  SELECT 'procedure p1' as result;
  SET v1= 10;
  SET v2= 100;
END//
DELIMITER ;
PREPARE s1 FROM 'CALL p1(?, ?)';
EXECUTE s1 USING @u1, @u2;
SELECT @u1, @u2;
=======================================================
Feature = BACKUP and RESTORE
Demonstrator = Peter
Version = 6.0
Sample Statement text =
quit
rm /data1/mysql-6.0/var/1
/data1/mysql-6.0.sh
DROP DATABASE d;
CREATE DATABASE d;
CREATE TABLE d.t (s1 INT);
INSERT INTO d.t VALUES (5);
BACKUP DATABASE d TO '1';             /* new statement! */
DROP DATABASE d;
SELECT * FROM d.t;                    /* now it's gone! */
RESTORE FROM '1';                     /* new statement! */
SELECT * FROM d.t;                    /* now it's back! */
=======================================================
Feature = EXECUTE IMMEDIATE (WL#2793)
Demonstrator = Konstantin
Version = 6.0-2793
Sample Statement text =
quit
/data1/mysql-6.0-2793.sh
DROP PROCEDURE IF EXISTS p1;
SET @@max_sp_recursion_depth = 5000;
EXECUTE IMMEDIATE 'SELECT 5';         /* literal! */
DELIMITER //
CREATE PROCEDURE p1 (name CHAR(255))
BEGIN                                 /* hara-kiri! */
  EXECUTE IMMEDIATE CONCAT('DROP PROCEDURE ', name);
  CALL p1(name);
END//
DELIMITER ;
CALL p1('p1');
=======================================================
Feature = Performance Schema
Demonstrator = Peter
Version = mysql-6.0-perf
Sample Statement text =
quit
/data1/mysql-6.0-perf.sh
SELECT * FROM performance_schema.EVENTS_WAITS_CURRENT\G
SELECT event_name,count_star,sum_timer_wait,max_timer_wait
 FROM performance_schema.EVENTS_WAITS_SUMMARY_BY_EVENT_NAME
 WHERE COUNT_STAR > 0 ORDER BY sum_timer_wait DESC LIMIT 5;
=======================================================
Feature = SIGNAL + RESIGNAL (WL#2110, WL#2265)
Demonstrator = Konstantin
Version = mysql-6.0
Sample Statement text =
quit
/data1/mysql-6.0.sh
DROP PROCEDURE IF EXISTS p;
DROP TABLE IF EXISTS t;
SIGNAL SQLSTATE '77777' SET MESSAGE_TEXT='Oops'; /* customized error! */
DROP TABLE t;                                 /* default error! */
DELIMITER //
CREATE PROCEDURE p ()
BEGIN
  DECLARE CONTINUE HANDLER FOR SQLEXCEPTION
  RESIGNAL SQLSTATE '22222';                  /* replaces default! */
  DROP TABLE t;                               /* activates handler! */
END//
DELIMITER ;
CALL p();
=======================================================
Feature = SHA2 (Bug#13174)
Demonstrator = Peter
Version = mysql-6.0
Sample Statement text =
quit
/data1/mysql-6.0.sh
SELECT sha2('a',256); /* Contributor = Bill Karwin */
=======================================================
Feature = Parameters view (WL#4301)
Demonstrator = Konstantin
Version = mysql-6.0
Sample Statement text =
quit
/data1/mysql-6.0.sh
DROP FUNCTION IF EXISTS f;
CREATE FUNCTION f (parameter1 SMALLINT)
RETURNS SMALLINT
RETURN 5;
SELECT SPECIFIC_NAME AS RNAME, ORDINAL_POSITION AS POS,
PARAMETER_MODE, PARAMETER_NAME, DATA_TYPE,
ROUTINE_TYPE
FROM INFORMATION_SCHEMA.PARAMETERS;    /* 2 rows! */
=======================================================
Feature = Partition by string (WL#3352)
Demonstrator = Peter
Version = mysql-5.1-wl3352
Sample Statement text =
quit
/data1/mysql-5.1-wl3352.sh
DROP TABLE IF EXISTS t1;
CREATE TABLE t1 (a CHAR, b CHAR, c CHAR)
PARTITION BY RANGE COLUMN_LIST(a,b,c)
(PARTITION p0 VALUES LESS THAN (COLUMN_LIST('a','b','c')));
=======================================================
Feature = Less VARBINARY (WL#2649)
Demonstrator = Konstantin
Version = mysql-6.0-wl2649
Sample Statement text =
quit
/data1/mysql-6.0-wl2649.sh
DROP TABLE IF EXISTS t1;
CREATE TABLE t1 AS SELECT CONCAT(1);
SHOW CREATE TABLE t1;
=======================================================
Feature = WEIGHT_STRING function (WL#3716)
Demonstrator = Peter
Version = 6.0
Sample Statement text =
quit
/data1/mysql-6.0.sh
DROP TABLE IF EXISTS t;
SET NAMES UTF8;
CREATE TABLE t (s1 VARCHAR(5) CHARACTER SET utf8);
INSERT INTO t VALUES ('a'),('Ã');
SELECT s1,WEIGHT_STRING(s1) FROM t;
DROP TABLE IF EXISTS t;
CREATE TABLE t (s1 VARCHAR(5) CHARACTER SET utf8
 COLLATE utf8_unicode_ci);
INSERT INTO t VALUES ('a'),('Ã');
SELECT s1,HEX(WEIGHT_STRING(s1)) FROM t;

Posted in Uncategorized | No Comments »

Performance Schema source on launchpad

April 20th, 2009

The MySQL Performance Schema feature is now publicly available.

The launchpad URL is
https://code.launchpad.net/~marc.alff/mysql-server/mysql-6.0-perfschema

Posted in Uncategorized | 1 Comment »

MySQL User Conference: Peter Gulutzan talks

April 17th, 2009

The MySQL User Conference starts April 20 2009. Please come and see:

New Foreign Keys in 6.1, with Konstantin Osipov and Peter Gulutzan, Wednesday April 22, 15:05. Originally the speaker was going to be Dmitri Lenev, the main developer … but alas, he can’t make it. However, the project lead (Konstantin) and the architect (Peter) constitute the largest pool of expertise on this subject in the whole continent.

Character Sets, with Alexander Barkov and Peter Gulutzan, Wednesday April 22, 20:30. This is a Birds-of-a-Feather get-together, so it’s not a show, just a chance to get together with other people who care about (for example) collation, Unicode, SJIS. Mr Barkov has worked with MySQL for several years and is the team lead for globalization.

Test Drive MySQL 6.1, with Peter Gulutzan and Konstantin Osipov, Thursday April 23, 11:55. This will not be a slide show, it will be an actual demonstration of foreign keys, supplementary Unicode characters, Falcon, BACKUP, EXECUTE IMMEDIATE, Performance Schema, SIGNAL + RESIGNAL, SHA2, the Parameters view, partitioning by string, reduced VARBINARY use, and the Weight_String function. Sorry, only a few minutes per topic.

The “Roadmap Shootout” keynote, originally scheduled for Wednesday morning, is canned.

There will be no “Performance Schema” session, alas, but we still intend to upload the source on Monday April 20, and you’ll catch short glimpses of the feature during the sessions Advanced Query Manipulation with MySQL Proxy or Extending MySQL Enterprise Monitor with Custom Advisors, Graphs, and Data Collections.

Although there are very few presentations by server developers this year, many developers who aren’t presenting are coming anyway. So if you don’t find anything on the schedule, just hang around in the corridors and you’re bound to see some interesting buttonholeable engineer wander along.

Posted in Uncategorized | No Comments »

Dependent Performance Schema tasks are public

April 13th, 2009

There are several tasks that depend on WL#2360 Performance Schema. They’re all public now, so you can find the description of the whole set on forge.mysql.com.

WL#2333 SHOW ENGINE … LOCK STATUS
WL#2360 Performance Schema
WL#2515 Performance statements
WL#3249 SHOW PROCESSLIST should show memory
WL#4674 PERFORMANCE_SCHEMA Setup For Actors
WL#4678 PERFORMANCE_SCHEMA Instrumenting File IO
WL#4689 Deadlock Monitor
WL#4813 PERFORMANCE_SCHEMA Instrumenting Stages
WL#4816 PERFORMANCE_SCHEMA Summaries
WL#4878 PERFORMANCE_SCHEMA Trace
WL#4895 PERFORMANCE_SCHEMA Instrumenting Table IO
WL#4896 PERFORMANCE_SCHEMA Instrumenting Net IO

Which one has priority for this quarter? We don’t know. We have to decide by the end of this month.

There are also three tasks that WL#2360 depends on:
WL#2373 Use cycle counter for timing
WL#4601 remove fastmutex from the server sources
WL#4876 Parse options before initializing mysys

In at least one person’s opinion those three tasks are already taken care of, or can be resolved without affecting our schedule greatly. There has been a complaint that the timing code from WL#2373 is not “optimal” (true); however, let’s hope that people’s concern at this phase will merely be whether it is “fast” and “safe”.

The main task, WL#2360, is still in code review. It is now clear that code review and Quality Assurance
will not finish in the next week or two. So the plan now is that, when we release the source code for public viewing on April 20 2009, it will be part of a separate launchpad tree.

Posted in Uncategorized | No Comments »

Globalization Tasks (Part 3 of 3)

April 3rd, 2009

Yesterday and the day before yesterday I started to say what the status is for “Globalization” tasks.
Today I continue and finish.

Worklog WL#4579 Latin9 (iso-8859-15) character set
Current Status: architecture review done 2009-03-23.
Version = 6.1
It will be possible to create columns and variables with character set = latin9. It’s similar to latin1 and its collations correspond to latin1 collations. It doesn’t add functionality but might save on the conversion time to/from latin1 for a few people.
Example:
”
mysql> CREATE TABLE t
-> (s1 char(1) CHARACTER SET latin9
->             COLLATE latin9_german2_ci);
Query OK, 0 rows affected (0.06 sec)
”

Worklog WL#4583 Case conversion in Asian character sets
Current Status: architecture review done 2009-02-19.
Version = 6.1
For character sets UJIS SJIS GB2312 CP932 EUCJPMS BIG5 EUCKR GBK, for functions UPPER UCASE LOWER LCASE, for fullwidth Latin Latin-with-accents Greek Cyrillic, MySQL will do case folding in a manner that is more correct.
For example:
”
mysql> create table t (s1 varchar(5) character set ujis);
Query OK, 0 rows affected (0.26 sec)

mysql> insert into t values (’àÃ’);
Query OK, 1 row affected (0.08 sec)

mysql> select upper(s1),lower(s1) from t;
+———–+———–+
| upper(s1) | lower(s1) |
+———–+———–+
| Àà       | àã        |
+———–+———–+
1 row in set (0.00 sec)
”
(In MySQL 5.1 the result is àÃ, àÃ.)

Worklog WL#4584 Internationalized number format
Current status: Code done 2009-04-01
Version = 6.1
The FORMAT() function will be “FORMAT(X,D [,locale_name] )”, that is, there is an optional third rgument, which affects the decimal point and the thousands separator. For example, a user specifying German locale will get ‘,’ and ‘.’ in the German way:
”
mysql> SELECT format(1234567.89,2,’de_DE’);
+———————-+
| format(1234567.89,2) |
+———————-+
| 1.234.567,89         |
+———————-+
1 row in set (0.00 sec)
”

WL#4616 Implement UTF-16LE
Status: not passed architecture review
Version = 6.1
The UTF16 character set can be big-endian or little-endian, depending whether you like to put the least significant byte first or last. MySQL supports big-endian. The plan is to support UTF-16LE (”Little Endian”) too.

WL#4617 Translate error messages to Tier1 languages
Status: not passed architecture review
Version = 6.1
Error messages need to be added or updated for Chinese Simplified, Japanese, English, French, German, Italian, Spanish. Volunteers welcome.

WL#4642 Greek locale for DAYNAME, MONTHNAME, DATE_FORMAT
Status: passed architecture review 2009-03-02
Version = 6.1
We had a feature request (Bug#39092) and contribution
from Nikolaos Tsarmpopoulos.
The DAYNAME() and MONTHNAME() and DATE_FORMAT() functions will produce appropriate Greek-language results if one sets @@lc_time_names appropriately.

WL#4649 Translate error messages into Tier 2 languages
Status: not passed architecture review
Version = 6.1
Error messages need to be added or updated for Catalan, Danish, Dutch, Finnish, Malay, Norwegian (Bokmål), Norwegian (Nynorsk), Portuguese/Brazil, Portuguese/Portugal, Swedish, Chinese Traditional (Hong Kong, Taiwan), Russian, Greek, Korean, Czech, Polish. Volunteers welcome.

This was the last of three blog postings re Globalization.
Maybe there will be a Birds of a Feather (BoF) about some language issue at the MySQL User Conference, if so we’ll make sure MySQL experts are there.

Posted in Uncategorized | No Comments »

Globalization Tasks (Part 2 of 3)

April 3rd, 2009

Yesterday I started to say what the status is for “Globalization” tasks.
Today I continue.

Worklog WL#1875 Case insensitive Czech collation
Status: not passed architecture review
Version = 6.1
This fills a minor gap, since our Czech collations for the cp1250 and latin2 character sets are case sensitive.
This task adds appropriate _ci (case insensitive) collations.

WL#2555 Standard Japanese collation support
Status: not passed architecture review
Version = 6.x
JIS (Japanese Industrial Standard) JIS X 4061-1996 specifies a standard collation for Japanese characters, with multiple levels and special rules.

WL#2673 Unicode Collation Algorithm new version
Status: passed architecture review 2009-03-23
Version = 6.x
MySQL is using Version 4.0.0 of the UCA (Unicode Collation Algorithm). That’s superseded. We’ll make new collations for the more recent UCA version.

WL#3090 Japanese Character Set Adjustments
Status: not passed architecture review
Version = 6.1
This task has shrunk a bit since we didn’t get feedback from the Japanese community for some parts, but there will be error messages for junk characters and a faster cp932-to-sjis conversion algorithm.

WL#3332 Korean Enhancements
Status: not passed architecture review
Version = 6.1
In euckr and cp949 character sets there are some reported discrepancies with standards, and collation feature requests.

WL#3997 New euckr characters
Status: passed code review
Version = 6.1
In the Korean euckr character set allow euro sign and registered sign, (but not Circled Hangul Ieung U i.e. “Postal code mark”).

WL#4013 Unicode german2 collation
Status: in code review
Version = 6.1
A DIN-2 (phone book) collation similar to latin1_german2_ci.

WL#4024 gb18030 Chinese character set
Status: not passed architecture review
Version = 7.1
MySQL can handle Chinese characters using several character sets (big5, gb2312, gbk, and of course all the Unicode sets).
But a newer character set, gb18030, is becoming popular in mainland China. We’ll support it too.

I’ll continue tomorrow.

Posted in Uncategorized | No Comments »

« Previous Entries

New Features In MySQL 6.x is proudly powered by WordPress MU running on Blogs.mysql.com.
Entries (RSS) and Comments (RSS).