Occasionally I hear the worry that MySQL might plan a feature that’s “half baked”. The term’s users include some of the world’s top MySQL experts so I’ll avoid a technical argument.

“In future we should not release a version with half-baked features and call it enterprise-ready.”
– Konstantin Osipov
http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/

“will Falcon be pushed hard as Innodb replacement even if it is half baked?”
– Peter Zaitsev
http://www.mysqlperformanceblog.com/page/2/?s=falcon&search_posts=true

As for me, though, I believe in features that others call “half baked”. I just don’t use the term much myself because it seems to convey a wistful regret. While “we’re halfway there” would generally be taken as a report of good progress.

The analogy seems to be with a cake: if you take a cake out of the oven and let …

While we were batting forth ideas about the SIGNAL statement (MySQL 7.0, we appreciate your patience), the question arose: what do we call the thingabummie number that MySQL uses for errors and warnings? You know, this thing …

mysql> crete table t;
ERROR 1064 (42000): You have an error in your SQL syntax; …

What do we call that ‘1064′? An old-timer might say SQLCODE but actually the SQL standard committee decided a decade ago to dump SQLCODE in favour of SQLSTATE, which is a string rather than a number. Besides, MySQL’s number doesn’t follow the old standard conventions for SQLCODE.

There were 7 choices for the term for the numeric return, that we’ll use eventually in SIGNAL / RESIGNAL / GET DIAGNOSTICS syntax and descriptions.

1. SQLCODE.
SQLCODE does not appear in the standard, but it is the DB2 term
…

A recent patch for 6.0 has given users the ability to delay SELECT statements in certain circumstances.

If there’s an INSERT DELAYED going on, then the SELECT can wait for it, or not, depending on the option that the user chooses. This is not the same as saying “there will be a SELECT DELAYED like INSERT DELAYED” — the conditions are not the same. But the new option (whatever it’s finally called) will help out in some debugging and synchronization scenarios.

A bunch of people held a meeting in California just before the last MySQL User Conference. They decided that tablespaces are not inside databases, and databases are not part of tablespaces. They are separate objects which overlap, for example table A can belong to tablespace X and database Y, while table B can belong to tablespace Y and database X. The result will be some restrictions regarding what you can do with tablespace maintenance statements, particularly for Falcon tablespaces.

The meeting participants also decided that there must be a new privilege, CREATE TABLESPACE, which will be required for CREATE TABLESPACE, ALTER TABLESPACE, and DROP TABLESPACE.

And there was talk about a new table for metadata: INFORMATION_SCHEMA.TABLESPACES.

Suppose you use Linux and suppose you have two tables, and their names are alike except for an uppercase / lowercase difference: ‘City’ and ‘CITY’.

Consider the statement
SELECT * FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = ‘City’;

In MySQL 5.0 you’ll see both tables.

In recent versions of MySQL 5.1 you’ll see only one table: ‘City’.

In later versions there’s a proposal — definitely not an accepted proposal, but this blog can be speculative — that the collation for INFORMATION_SCHEMA.TABLES.TABLE_NAME should be changed to reflect this fact. Currently TABLE_NAME is UTF8_GENERAL_CI. If the proposal goes through, then the collation becomes UTF8_BIN for TABLE_NAME and for a few other columns that end with _NAME (but not all of them), except for Falcon tables, but only on some platforms where case is significant. On other platforms, such as Windows, the collation would be …

The things that might change in future versions for the BINARY and VARBINARY data types are:

* We’ll drop the last vestiges of the idea that they’re not really data types, that they’re just variants of char/varchar data types. The product has some quirks that reflect that old idea, but it will no longer be tenable after the next version of the SQL standard says firmly: they’re data types. This will affect, for example, some connectors.

* The result of some functions will cease to be VARBINARY. For example if you say
CREATE TABLE xm AS SELECT CONCAT(’a',0);
SHOW CREATE TABLE tm;
you’ll see that the result of concatenating a char with an integer is a varbinary. But we now feel that a more useful result data type would be char or varchar with the connection character set.

* We’ll allow BINARY VARYING as an equivalent for VARBINARY in definitions.

* We’ll allow X’AB’ ‘CD’ …

We (in the Telecom team at MySQL) have been debating whether we should call this blog 'MySQL in Telco' or 'MySQL in Communications'. Naming discussions tend to take long time, and this one was no exception.

From a US perspective, it appears that Telecom is an outdated term. Wireless carriers and cable television companies do not consider themselves as Telecom companies. Maybe for this reason, large US-headquartered vendors including Sun, HP, IBM and Oracle all have a 'Communications & Media' practice.

From a European perspective, Telecom is used for equipment vendors and service providers. Companies like Logica, Cap Gemini, Atos Origin and TietoEnator refer to the vertical as 'Telecom & Media'.

Of the global SI's in India, Wipro and TCS refer to Telecom while Infosys talk about Communications.

As a working title we at one time used 'MySQL blablabla' blog, and funnily enough, there was a compromise suggestion to …

We (in the Telecom team at MySQL) have been debating whether we should call this blog 'MySQL in Telco' or 'MySQL in Communications'. Naming discussions tend to take long time, and this one was no exception.

From a US perspective, it appears that Telecom is an outdated term. Wireless carriers and cable television companies do not consider themselves as Telecom companies. Maybe for this reason, large US-headquartered vendors including Sun, HP, IBM and Oracle all have a 'Communications & Media' practice.

From a European perspective, Telecom is used for equipment vendors and service providers. Companies like Logica, Cap Gemini, Atos Origin and TietoEnator refer to the vertical as 'Telecom & Media'.

Of the global SI's in India, Wipro and TCS refer to Telecom while Infosys talk about Communications.

As a working title we at one time used 'MySQL blablabla' blog, and funnily enough, there was a compromise suggestion to …

If you use replication with MySQL and memcache at the same time you have the problem to make sure that the memcached and the slave are in sync. If you announce the memcached to mark a entry as dirty and let it update the value from the slave BEFORE it is updated, you fetch a old value.

The easiest way to ensure that memcache is always notified after the slave is updated, you can use ... well ... replication. MySQL 5.1 brings Row Based Replication that makes this kind of applications a lot easier.

I'm not there to present you a Proof of Concept, I'm only close enough to explain the idea:

• Slave fetches records from Master
• Slave applies the records
• Slave exposes its changes as replication stream to the MySQL Proxy
• MySQL Proxy decodes the RBR records, extracts the Primary Key and updates the content in the memcache server

The MySQL Proxy acts as replication client …

There is much discussion of why MySQL is more widely adopted than PostgreSQL. The discussion I’ve heard is mostly among the PostgreSQL community members, who believe their favorite database server is better in many ways, and are sometimes puzzled why people would choose an inferior product.

There are also many comparison charts that show one server is better than the other in some ways. These don’t really seem to help people with this question, either!

I can’t answer for everyone, but I can put it in the form of a question: if I were to replace MySQL with PostgreSQL, what things do I rely on that would become painful or even force a totally different strategy? The answer turns out to be fairly simple for me: replication and upgrades.

Replication

Love it or hate it, MySQL’s built-in replication is …