Yesterday I complained about PostgreSQL's lack of the GROUP_CONCAT function, today I received a mail from Christopher Kings-Lynne with the solution: the mysqlcompat functions, which can be found at http://pgfoundry.org/projects/mysqlcompat/.

Besides an implementation of GROUP_CONCAT (not very equal to MySQL's implementation, but similar), there are many other functions that we are used to from MySQL. I installed the functions and tested the GROUP_CONCAT function and it allowed me to solve my problem without any pain. So for everyone who's used to work with MySQL and has to do some work with PostgreSQL, it's good to know that this collection of functions (in total there are 158 functions, including all the different overloading variants) exists.

Many of the developers here at MySQL dual boot between some type of Linux distro and some flavor of Windows.  They may need to make sure a new feature works on Windows or may need to work on an installer for the package.  More than once I've thought that it would be nice if Windows could read and write to my Linux drives. 

There was certainly no technical reason why it couldn't be done since Windows allows the installation of third-party file system drivers.  No one cared enough to bother, until now.  The website indicates that it supports all normal functions of a file system such as reading, writing, and file/directory operations.  Has anyone use this? 

A friend recently gave me a used copy of O'Reilly's Learning the bash Shell, 2nd ed. which I've been perusing a bit here and there, not really with the objective of learning all there is to know about bash in one swell foop, but rather to have bits of it lurking about in the back of my head for future reference. One of those bits came in handy a couple of days ago. As part of my job, I need to compile new builds of MySQL from the sources pretty frequently, and when I file a bug report, I like to be able to include the date the version I used was built. I mean, it's not like I can't do something like ls -l ~/bin/mysql/bin/mysql | cut -d' ' -f7 to get the file creation date for the client binary, but I thought it would be cool to have it in the MySQL version string so I didn't have to exit mysql or switch to another shell. I already knew that MySQL can be built using a --with-server-suffix option that adds an arbitrary string to the output of …

A friend recently gave me a used copy of O'Reilly's Learning the bash Shell, 2nd ed. which I've been perusing a bit here and there, not really with the objective of learning all there is to know about bash in one swell foop, but rather to have bits of it lurking about in the back of my head for future reference. One of those bits came in handy a couple of days ago. As part of my job, I need to compile new builds of MySQL from the sources pretty frequently, and when I file a bug report, I like to be able to include the date the version I used was built. I mean, it's not like I can't do something like ls -l ~/bin/mysql/bin/mysql | cut -d' ' -f7 to get the file creation date for the client binary, but I thought it would be cool to have it in the MySQL version string so I didn't have to exit mysql or switch to another shell. I already knew that MySQL can be built using a --with-server-suffix option that adds an arbitrary string to the output of …

MySQLs Certification Manager outlines the upcoming changes in the MySQL certification program, and why those changes were made.

I'm happy it turned out to be that simple, but the amount of such bugs and devastating consequences are humiliating.
Bug#7209 is a case of an intermittent failure when the best brain of Support department and dozens of man hours had to be spent to track the issue down to a repeatable test case. And the cause is such a trivial design mistake:

typedef struct st_hash {
  uint key_offset,key_length;           /* Length of key if const length */

  uint records,blength,current_record;
  DYNAMIC_ARRAY array;                          /* Place for hash_keys */

  /* cut */
} HASH;

gptr hash_search(HASH *info,const byte *key,uint length);

gptr hash_next(HASH *info,const byte *key,uint length);

Now, where does hash_next get the current position of the search? In …

Tonight at a party I was asked the question "so when is 64bit?"

The answer is now. Hell, this has been the answer for the last half of 2005. If you are buying servers do not consider 32bit machines. Don't take any application serious unless it can make reasonable usage of a 64bit machine.

I'm serious, don't waste your time on 32bit machines. They can't access enough memory, and the trick to scaling (right after learning how to partition your problem) is "buy more memory".

You will want to use that memory, whether you are using MySQL, a webserver, or even an application server. The key will be 64bit address space.

And if you are a developer, stop thinking about 32bit memory address space. Think about big massive chunks of memory you can allocate and optimize knowing that "modeling the data for memory" is more important then "modeling the data for disk".

The desktop might be …

Tonight at a party I was asked the question "so when is 64bit?"

The answer is now. Hell, this has been the answer for the last half of 2005. If you are buying servers do not consider 32bit machines. Don't take any application serious unless it can make reasonable usage of a 64bit machine.

I'm serious, don't waste your time on 32bit machines. They can't access enough memory, and the trick to scaling (right after learning how to partition your problem) is "buy more memory".

You will want to use that memory, whether you are using MySQL, a webserver, or even an application server. The key will be 64bit address space.

And if you are a developer, stop thinking about 32bit memory address space. Think about big massive chunks of memory you can allocate and optimize knowing that "modeling the data for memory" is more important then "modeling the data for disk".

The desktop might be …

MySQL's GROUP_CONCAT command is a phantastic thing, it can simplify big efforts to a small piece of work that would not even be worth mentioning - if the way that the problem is being solved wouldn't be so nice ;-).

The reason why I'm writing this is because I have to work on such a task with PostgreSQL, and I already know that it will be quite a tough piece of work, which could be solved with MySQL within seconds. So to everybody, who doesn't still know the power of the GROUP_CONCAT aggrigate function, here's a little example, which I think is self-explaining:

mysql> CREATE TABLE group_concat_test (
    ->   id INT UNSIGNED NOT NULL auto_increment PRIMARY KEY,
    ->   _key INT UNSIGNED NOT NULL,
    ->   _value CHAR(1) NOT NULL);
Query OK, 0 rows affected (0.00 sec)


mysql> INSERT INTO group_concat_test
    ->    (_key, _value) VALUES
    ->    (1, 'b'),
 …

I wish everybody envolved with MySQL: developers, employees, the management and of course everybody in the MySQL community a great and successful new year 2006!

It will be exciting to see what the new year will bring - I guess, a lot of great things again. So keep on rocking everybody :-)!