Die schöne Welt der miracee

Aus gegebenen Anlass erläuter ich heute das Encoding Handling von MySQL.

Der Experte unterscheidet zwischen:
1) Server Encoding
2) Client Encoding
3) Environment Encoding

Zum besseren Verständnis versuche ich das ganze bildlich an der Kommunikation mit Ausländern zu beschreiben. Stellt Euch einfach vor Ihr seid in Italien im Urlaub und möchtet von einem Italiener den Weg zu einer Sehenswürdigkeit wissen.

Environment Encoding

Das ist die Sprache, die Ihr standardmäßig sprecht. Als Deutscher also deutsch, als Franzose französisch, als Italiener italienisch, ...

Auch Computer haben eine Sprache, die sie standardmäßig sprechen. Für die Nutzung der MySQL CLI unter Windows ist es notwendig in der CMP das Kommando CHCP auszuführen. Das Ergebnis ist die Sprache, die hier für Windows plus MySQL CLI interessant ist. Ein deutsches Windows spricht hier Codepage 850 (CP850).

Unter Unix/Linux kommt es auf Euren Benutzer und dessen Einstellungen an. Auf modernen Linuxsystemen wird standardmäßig UTF8 verwendet, das muß aber nicht zwangsweise so sein.

Hier ist es außerdem noch wichtig, was Ihr genau für eine Umgebung verwendet. Als Beispiel: KDE-, Gnome-Terminal oder Konsole.

Bei einem Gnome Terminal gibt es oben unter Terminal den Punkt: Zeichenkodierung festlegen. Dort könnt Ihr sehen, welches Encoding das Terminal verwendet. Bei KDE gibt es oben in der Menüleiste irgendwo einen ähnlichen Punkt.

Solltet Ihr in Eurem Terminal nicht fündig werden, welches Encoding verwendet wird, so ist es zu 90% das Encoding was Euer Nutzer als locale verwendet und Ihr könnt es hier genauso rausfinden wie für die Konsolennutzung.

Auf der Konsole wird die Spracheinstellung von locale verwendet.

$ locale

hier sollte jetzt eine Ausgabe kommen, die Euch verrät, was verwendet wird.

Achtung unter Unix/Linux: Immer bedenken, wird hier nur C oder ASCII eingetragen, haben deutsche Umlaute 'äüöß' keine Chance. In diesem Fall solltet Ihr das Encoding erstmal ändern. Entweder auf ISO-8859-15 oder gleich auf UTF8.

Unter Windows habt Ihr keine Chance das Encoding zu ändern. Bei deutschen Windows wird CP850 verwendet und wenn Ihr z.B. Chinesische Zeichen speichern wollt, die von der Codepage nicht unterstützt werden, habt Ihr Pech. Abhilfe schafft hier entweder ein chinesisches Windows oder Ihr versucht Euer Glück mit Unix/Linux.

Wie sich Mac OS X hier verhält, weiss ich nicht.

Windows ist vergleichbar mit jemandem, der nur und ausschliesslich deutsch spricht. Also entweder spricht der Gegenüber in Italien  deutsch oder die Auskunft nach dem Weg bleibt unverstanden.

Unix/Linux spricht deutsch als Muttersprache, kann aber zum Beispiel auch noch Englisch, Hebräisch oder Französisch. Wenn es hier zu Verständigungsschwierigkeiten kommt, kann auf eine andere Sprache gewechselt werden.

In der Praxis in der Computerwelt, wird dieser Sprachwechsel an dieser Stelle nur verzogen, wenn wirklich Zeichen gebraucht werden, die das Encoding nicht kennt oder wenn das Encoding ein nicht vom System (MySQL) unterstütztes Encoding ist.

Wenn der Italiener gegenüber deutsch versteht, versucht man ja auch erstmal deutsch mit ihm zu sprechen und wechselt nicht unbedingt sofort auf englisch. Spricht der Italiener nur italienisch und französisch und ich deutsch, englisch, französisch, dann sollte ich wohl oder übel auf französisch wechseln.

Die deutschen haben 'äöüß', die Schweden 'åø', die Tschechen noch ein paar andere Buchstaben und die Russen gleich ein komplett anderes Alphabet. Damit sich dieses unter einem Hut vereinen läßt, wurde UTF8 erfunden. UTF8 unterstützt den kompletten Zeichensatz von West- und Osteuropa plus noch Teile von Asien. Ein paar wenige Sprachen dieser Erde sind nicht mit UTF8 abgedeckt, aber dass ist in den meisten Fällen irrelevant.

Grob lässt sich sagen, UTF8 reicht für internationale Kommunikation völlig aus. Wenn Du UTF8 sprichst, kann Dich 98% der Erde verstehen. In der Computerwelt kann Dich Windows erstmal nicht verstehen. Aber das ist, wie nachfolgend klar wird, erstmal nicht schlimm.

Client Encoding

!!! ACHTUNG !!! Das nachfolgende gilt nur fürdie MySQL CLI und andere Clients die Daten binär weiterleiten. Connectors wie MyODBC oder JDBC oder auch Workbench oder die älteren MySQL GUI Tools regeln alles vollautomatisch und es sollte nichts manuell geändert werden. Bei PHP ist gründlich nachzudenken und nachzulesen. Siehe auch weiter unten.

Dein Hirn ist das Envrionment und Dein Mund ist der Client. Der Italiener ist der Server. Dein Hirn ist standardmäßig auf deutsch eingestellt, womit aus Deinem Munde deutsch herauskommt. Als erstes solltest Du herausfinden, ob der Italiener deutsch spricht:

Du: "Deutsch? English? Francais? Italiano?"
Er: "Deutsch, English, Italiano, Chinese, Hebrew"

In MySQL ist das ganze jetzt so:
Du weisst Dein Environment Encoding (sagen wir jetzt einfach es ist Codepage 850) und nun schaust Du ob dieses Encoding von MySQL unterstützt wird. Hierzu benutzt Du die CLI:

mysql> SHOW CHARSET;

Du findest heraus, dass es dort CP850 gibt. Das ist perfekt für Dich.

Benutzt Dein Environment UTF8 findest Du dort heraus, dass MySQL UTF8 unterstützt. Nutzt Dein System ISO-8859-15 dann stellst Du fest, das was am besten passt ist latin1.

Aber vorsicht hier unter Linux mit den Eurozeichen. Das ist genauso, als wenn der Italiener zwar perfekt Englisch aber nur gebrochen Deutsch spricht. Besser hier doch das Environment auf UTF8 stellen und in UTF8 kommunizieren. Bei dem Italiener würde man sich hier ja auch auf Englisch einigen.

Jetzt sagst Du dem Italiener, dass Du mit ihm in Deutsch kommunizieren möchtest:

Du: "Ok, dann sprechen wir in deutsch"

Wie ich oben sagte, der Italiener ist der Server und Dein Mund der Client.

Auch in MySQL solltest Du jetzt dem Server mitteilen, welche Sprache Du verwenden möchtest. In der CLI machst Du das mit dem Befehl:

mysql> SET NAMES <der_charset_der_zu_meinem_environment_encoding_passt>;

Unter deutschen Windows also:

mysql> SET NAMES CP850;

Für UTF8:

mysql> SET NAMES UTF8; 

Nun weiß der Italiener, dass alles was von Dir gesagt wird, deutsch ist und er kann es völlig automatisch und transparent vestehen und/oder ggf. in Italienisch übersetzen.

Ein nettes Beispiel aus dem Leben, was passieren kann in Schriftform, wenn nicht vorher klar ist, welche Sprache verwendet wird:
Englisch oder Deutsch?
"die" => ist das jetzt das englische Wort für sterben oder der weibliche deutsche Artikel?

Das ganze wird erst klar, wenn man den gesamten Text liest oder wenn irgendwo vorher definiert wurde, dass der Text englisch/deutsch ist.

Einem Computer muß dieses stets vorher erläutert werden:

Du: "Achtung Computer jetzt kommt ein Text in englisch"
Computer: "ok"
Du: "Die"
Computer: "Nein, ich will noch nicht sterben."

Wenn Du weisst, dass viele Deiner Clients ein und dasselbe Environment Encoding nutzen, kannst Du das ganze auch in der my.cnf/my.ini machen.

Beispiel für UTF8:

[client]
default-character-set=UTF8

Client Encoding und PHP

Für PHP gilt erstmal dasselbe wie für die CLI. Doch bei PHP plus Webserver, Browser, Datenbank .... Da wird das Encoding des Browsers verwendet, was der Nutzer nutzt. Schwer herausfindbar. Die Empfehlung ist hier: PHP sollte daher dafür sorgen, dass der Browser stets UTF8 spricht. Der Webserver sollte UTF8 sprechen. Sämtliche Tabellen und Spalten in der Datenbank sollten UTF8 sein. Mit einem homogenem UTF8 System ist man stets auf der sicheren Seite.

Server Encoding

Wie bereits erwähnt, ist in meinem Beispiel der Italiener der Server.
Sein Hirn verarbeitet intern alles in Italienisch.

Er kann allerdings: "Deutsch, English, Italiano, Chinese, Hebrew"

Das heisst, Du gibst ihm zum Beispiel einen deutschen Text und er speichert ihn in seinem Hirn in Italienisch ab, oder er lässt ihn auf deutsch oder aber auch kann er Dir bei einer deutschen Frage auch eine englische Antwort geben. Oder wenn ihn der Chinese fragt, was Du gesagt hast, kann er es ihm in chinesisch geben.

Das ganze macht der Italiener völlig automatisch und transparent für Dich.

Wenn Du ihm sagst, speicher meinen deutschen Text doch bitte in englisch, so übersetzt er ihn und speichert ihn in englisch.

Genauso, wenn er die Wegbeschreibung für Dich in italienisch findet, überreicht er Dir die deutsche Übersetzung.

Gibst Du dem Italiener einen holländischen Text und hast ihm vorher gesagt, es sei ein deutscher Text, dann versucht er, alles in deutsch zu interpretieren und hat eine Reihe von Fragezeichen in seinen Augen. Wenn er dieses jetzt noch zu Vergleichszwecken ins Italienische übersetzen sollte, kommt noch mehr Müll dabei heraus.

Das Server Encoding ist das Encoding was der Server intern verwendet.

In der ganz untersten Ebene verwendet MySQL utf8. Das ist aber irrelevant. Bei einem Menschen ist mir für diese Ebene kein Name für die Sprache bekannt. In welcher Sprache denkst Du? Mein Hirn hat erst den Gedanken und versucht ihn dann in Worte zu fassen. In dem Moment, wo mein Hirn den ersten Ansatz des Gedanken hat, ist das ganze noch sprachlos. Irgendwelche Elektronen, die das Hirn erst in Worte fassen muss. Auf dieser Ebene spricht MySQL UTF8.

Die Ebenen darüber sind interessanter. Default verwendet MySQL hier LATIN1. Das ist historisch begründet. MySQL stammt einfach aus einer Zeit, bevor UTF8 als Default Sprache auf Unix/Linux Gang und Gebe war. Eine Änderung des Default Wertes in MySQL würde bedeuten, dass einfach zuviele alte Datenbanken/Anwendungen nicht mehr einwandfrei funktionieren würden.

Daher sollte man im Hinterkopf haben, diesen Default Wert einfach von Latin1 auf utf8 zu ändern.

Das geht in der my.cnf/my.ini mit:

[mysqld]
character-set-server=utf8

Das ganze lässt sich aber auch datenbankspezifisch festlegen, beim anlegen einer Datenbank:
CREATE DATABASE <eine_datenbank> CHARACTER SET UTF8;

Sofern jetzt nicht explizit etwas anderes gesagt wird, wird für alle Tabellen und Spallten dieser Datenbank zur Speicherung UTF8 verwendet.

Jedoch lässt sich bei MySQL das Encoding für die Speicherung bis zur Spalte herunter einzeln festlegen.

CREATE TABLE .... (....) CHARACTER SET UTF8;
CREATE TABLE ...(... <eine_spalte> VARCHAR(100) CHARACTER SET UTF8 ...) ...;

Sagen wir für unseren Italiener UTF8 sei englisch. Der Italiener bekommt einen deutschen Text, den übersetzt er nun völlig automatisch und transparent ins Englische und speichert ihn in englisch in seinem Hirn ab.

Egal was und wie der Italiener es hereinbekommt, sobald Übersetzungsregelungen vorliegen, übersetzt und speichert er es in dem gewünschten Format. Kennt er keine Überesetzungregel, speichert er ein Fragezeichen.

Das macht der Server auch. Wenn versucht wird ein Tschechisches Zeichen in einer LATIN1 Spalte zu speichern und LATIN1 kennt dieses Zeichen nicht, dann wird ein Fragezeichen gespeichert.

Wird versucht ein in CP850 eingebener Umlaut in UTF8 zu speichern, dann übersetzt der Server den Umlaut automatisch und transparent in UTF8. Möchte ich den Umlaut nun aus der Datenbank wieder bekommen und in CP850 angezeigt bekommen, so kümmert sich der Server hier völlig transparent darum, dass es nach meinen Wünschen geschieht.

Voraussetzung hierfür ist, dass das Client encoding auf den richtigen Wert gesetzt wurde.

Überprüfung

Welches Client Encoding ist eingestellt?

mysql> SHOW VARIABLES LIKE '%char%';

Die Variablen character_set_client, character_set_result, character_set_connection spiegeln das Client Encoding wieder. Die drei Variablen sollten niemals einzeln geändert werden. Nur durch SET NAMES oder default-character-set (in my.ini). Die drei Variablen sollten immer (ausser bei Connectors oder verwendeten MySQL Tools) alle drei auf denselben Wert gesetzt sein.

Wie finde ich heraus, ob mein Text richtig abgespeichert wurde?

Für deutsche ist das ein einfacher Test. Meistens geht es um LATIN1, UTF8 und ASCII. Ein Umlaut (egal ob ä, ö, ü oder ß) braucht in LATIN1 1 byte, in UTF8 2 byte und in ASCII ist es ein Fragezeichen.

Das Wort Bär hat in Latin1 die Länge 3 und in UTF8 die Länge 4.

mysql> SELECT LENGTH(<entsprechende_spalte>) FROM <entsprechende_tabelle>;

Wenn hier jetzt für das Wort 'Bär' 6 herauskommt, ist irgendwas falsch. Kommt hier 4 heraus und die Spalte ist Latin1, dann ist auch etwas falsch.

Falsch abgespeicherter Datensätze lassen sich nur sehr schwer bis gar nicht reparieren. Sobald MySQL angefangen hat, Fragezeichen statt Buchstaben abzuspeichern, ist alles vorbei. Keine Reparatur möglich.

Welchen Charset die Spalte zur Speicherung verwendet, lässt sich herausfinden mit:

mysql> SHOW CREATE TABLE <entsprechende_tabelle>;

In der Beschreibung steht es entweder direkt bei der Spalte, oder wenn dort nichts angegeben, am Ende der Tabelle. Ist nichts in der Spalte direkt angegeben, nimmt das System den Tabellencharset.

Falsch abgespeicherte Daten, bei denen keine Umwandlung in Fragezeichen passiert ist, lassen sich durch Spatenmodifizierung und den Umweg über eine binäre Zwischenspeicherung evtl. noch reparieren.

mysql> ALTER TABLE .... MODIFY .... VARBINARY(100) ....;
mysql> ALTER TABLE .... MODIFY ... VARCHAR(100) CHARSET ...;

Ratsam ist immer, erstmal eine Kopie vom Original zu machen und mit der Kopie die Schritte auszuprobieren.

Außer LENGTH() kann auch noch die Funktion HEX() zum Troubleshooting herangezogen werden.

LENGTH() gibt stets in MySQL die Länge in Bytes zurück.

Zusammenfassung:

Auf Windows stets SET NAMES CP850 verwenden, bevor irgendetwas ausgeführt wird.
Auf anderen Systemen erst das Environment Encoding herausfinden und dann SET NAMES <mein_encoding> verwenden.

Erst nachdenken, bevor Daten falsch abgespeichert werden.

Weitere Links:

http://forge.mysql.com/w/images/b/b6/How_to_Use_Charsets_and_Collations_Properly.pdf

FrOSCon 2008 was a real success (http://www.froscon.org).

I have only three complains for the organisation:

1) next year, please take care not to schedule two PostgreSQL talks during the same time.
2) don't forget to put water for the speakers into the presentation rooms. I recognised it before I started and got immediately a six pack water. Anyway, usually there should be glasses and drinking stuff without the speaker has to take care about it.
3) I didn't get food and coffee because it always was out (i.e. at lunch during the first/last session after/before visitors lunch break. Consider, exhibitors only can take lunch before or after visitors lunch break because during break you have too much visitors at the booths).

Anyway, the FrOSCon was great. We have had lots of visitors at the PostgreSQL booth and also my workshop was full. The same with Bernd's talk. For both my workshop and Bernd's talk we got lots of positive feedback.

At the PostgreSQL booth most visitors asked for migration from MySQL to PostgreSQL. Also often we got questions about HA/Cluster/Replication. Additionally there was a huge interest in Postgis.

Lots of visitor complained that tools like CMS tools just offer an interface to MySQL and not to PostgreSQL.

Additionally OpenOffice community asked for a native interface for OpenOffice to PostgreSQL.

As usual, lots of visitors just visited the booth to let us know how they like PostgreSQL and how less problems they have with it.

Thanks to the FrOSCon organisation who made this great event possible.

I think, when FrOSCon will grow further on, then I can see that it will be from international interest in 2010.

I am glad to announce FrOSCon 2008 (http://www.froscon.org).

This was always a great conference and I will hope that it will be great this year too.

I will be responsible for the PostgreSQL booth. The booth will be in front of AllBSD and next to MySQL. Honestly both MySQL and PostgreSQL are happy that the booths are next to each other because both fear a helper bottleneck. If there will be a bottleneck then we can help each other. This not means, that our old agreement with AllBSD didn't exist anymore. Of course if PostgreSQL or AllBSD have a bottleneck of resources/Flyers then they will help each other too.

If you want to join the FrOSCon and you want to help me with the PostgreSQL booth, please don't be too shy to let me know.

Besides the booth I will have a 3.5 hour workshop and Bernd Helmle will have a talk about PostgreSQL troubleshooting.

Unfortunately, at the last draft of the program my workshop and the talk will be at the same time. I already talked to the FrOSCon organisation and they were sorry for this mistake. They will look for a solution here. Because I know how difficult this talk organisation is, I already offered that we schedule my workshop for one more hour and I will make a break for Bernd's talk.

We will guarantee you, that you will get the possibility to take both Bernd's talk and my workshop.

The workshop is scheduled in English. If there will be non German understanding listeners then I will do it in English. If there will be only Germans then of course I will do it in German. My slides will be in English anyway. So, if you think about listening to my workshop but you fear English just look into the room at the beginning. Maybe you have luck and there will be only Germans. If there will be only a single non German understanding listener then I will switch to English and do it in English.

Of course we will collect donations for the PostgreSQL Project at the FrOSCon too.

We will have a limited number of plush elephants, Mugs, bags, anti stress balls, T-Shirts and also you can get pins, pens and other pins for donation.

Es war wohl der schlechteste LinuxTag, den ich je gesehen habe.

Erstens bekamen nicht alle Aussteller auch Ausstellerausweise sondern viele Aussteller waren via E-Ticket auf der Messe. Das bedeutet, dass hier bei den Besucherzahlen, die Zahl der Aussteller mit E-Ticket abgezogen werden müsste.

Von der alten LinuxTag Atmosphäre war gar nichts mehr zu spüren. Alles war ziemlich stark auf Kommerz ausgerichtet.

Auch gab es wohl keine Schlafplätze für Helfer und Projekt-Standbetreuer für wenig Geld mit Isomatte und Schlafsack.

In der U-Bahn beschwerten sich sehr viele darüber, dass die Vorträge doch sehr marketinglastig waren. Hierzu kann ich nichts sagen, da ich keinen Vortrag gehört habe. Es gab nicht einen Vortrag, der mich wirklich interessiert hätte. Richtig tieftechnische Vorträge habe ich im Programm allerdings auch nicht gefunden.

Traurig fand ich auch die Größe der OpenSource Stände. KDE, Debian und die BSDler waren dieses Jahr doch erheblich kleiner als sonst. Dazu kam, dass Debian noch quasi in der Ecke hinter Ubuntu versteckt war.

Bei einem Aussteller konnte ich beobachten, dass er mit seinen Besuchern auf dem Fußboden sitzen musste, da es wohl keine Stühle gab.

Besucher waren auch sehr wenig dort.

Am Sun Stand hatten wir, solange ich dort stand in drei Tagen wahrlich 2 wirkliche Besucher. Der Rest war Aussteller bespassen Aussteller. Die OpenSolaris Jungs hatten ein paar mehr Besucher aber auch nicht wirklich viele.

Am Oracle Stand hab ich auch nur einmal einen Besucher gesehen in drei Tagen.

Wirklich nett fand ich die Hilfsbereitschaft. Durch die Miesere, dass PostgreSQL keinen Stand bekommen hatte (er wurde wohl von der Orga abgelehnt), haben mir unwahrscheinlich viele andere Projekte und auch Firmen angeboten, dass ich eine Ecke für PostgreSQL an Ihrem Stand haben könnte.

Vielen Dank hier. Wenigstens stimmte noch die Atmosphäre und die Hilfsbereitschaft unterhalb der Aussteller.

Wirklich erschreckend fand ich auch das Know How, was ich an einigen Ständen vorfand.

Die Linuxstände testete ich auf Wissen nach Dateisystemen:
"Was gibt es für Dateisysteme? Was kann empfohlen werden? Ext3, XFS oder ReiserFS? Wann macht es Sinn was zu nehmen?"

Loben lässt sich hier Debian und OpenSuse. Hier konnten mir die Standbetreuer haarklein alles erklären. Eine peinliche Vorstellung lieferten hier jedoch Ubuntu und Fedora.
Waren hier wirklich nur Marketing Leute am Stand?

Fazit vom LinuxTag:
Kaum Besucher in den Ausstellungshallen.

Irgendwie lohnenswert war das ganze wohl weder für die Besucher noch für die Aussteller, in meinen Augen.

Ob es hier wirklich Sinn macht, nächstes Jahr nochmal zu versuchen, einen PostgreSQL Stand zu bekommen, bleibt fraglich. Ich glaube mit Chemnitz, FOSDEM und FrOSCon gibt es genügend gute Alternativen.

Es war einfach "Spitze".

Am dritten und vierten Tag gab es den ganzen Tag Vorträge. Alle Vorträge waren ausgesprochen kurzweilig.

Fürchterlich enttäuscht war ich, als ich am Freitag nachmittag feststellte, dass ich bereits im letzten Vortrag sitze und die Konferenz damit vorbei ist.

PGCon kann ich nur empfehlen, eine wirklich sehr gute Konferenz.

Es wird immer voller hier in Ottawa.
Während es am ersten Tag noch recht familiär war, platzte heute der Hörsaal bei beiden Tutorials sitzplatzmäßig fast aus dem Nähten.

Materialized Views that Really Work, Dan Chak

How to simply leverage view materialization for even the most complex cases

Ein wirklich gutes Tutorial für Anfänger.
Dan fing mit Grundlagenerklärung an. Beispielsweise: "Was ist ein View?" oder "Was bedeutet 'materialised" überhaupt?".

Sehr gut herausgehoben wurden die Performancevorteile von materialised Views.

Database Anti-Patterns, Robert Treat

Everyone else is doing it wrong, why can't we?

Was sollte man nicht machen?
Robert fing hier mit Datentypen an. Ein nettes Beispiel: Telefonnummern, auch wenn dieses Wort das Wort Nummer enthält, sollten nicht als numerischer Datentyp in einer Datenbank abgelegt werden.

Weiter ging das Tutorial mit Normalisierung und die gut durchdachte Denormalisierung oder gar die Vermeidung der Denormalisierung durch Verwendung von materialisierten Views.

Hier kann ich nur zustimmen. Generell erst einmal alles für 3 NF durchdenken und erst, wenn der Flaschenhals bekannt ist, eventuell, wenn es wirklich notwendig erscheint, gezielt und wohl überlegt (auch an die Folgen denkend) Denormalisieren. Oder durchaus erst einmal sich Gedanken machen, ob sich die Denormalisierung nicht mit materialisierten Views vermeiden lässt.

Weiter ging es mit Keys und die sinnvolle Bezeichnung von Keys (nicht nur "id" als Key verwenden) sowie wie sinnvoll die Verwendung von Foreign Keys und die Einhaltung von referentieller Integrität ist.

Robert erklaerte viele weitere Dinge ...

Alles anzuführen, würde hier einfach zuviel werden.

Ein sehr kurzweiliges Tutorial.

Tutorial: GUCs (Grand Unified Configuration settings), Josh Berkus

Das gesamte Tutorial ging über drei Stunden. Den gesamten Inhalt wiederzugeben wäre hier zuviel.

Wie üblich für Josh Berkus war es ein sehr kurzweiliges Tutorial.

Josh ging alle 149 Konfigurationsvariablen einzeln durch und erklärte diese.

Hier ein paar interessante Dinge, über die ich vorher nie nachgedacht habe:

SIGHUP:

Bei einem Softneustart von PostgreSQL nach dem einkommentieren einer Variable in der postgresql.conf, die Variable wird erkannt und verwendet. Jedoch wird eine Variable auskommentiert und danach lediglich ein SIGHUB gemacht, so wird die Variable weiterhin verwendet und nicht wie erwartet ignoriert.

Dieses Verhalten ist in PostgreSQL 8.3 angepasst worden. In PostgreSQL 8.3 werden sowohl ein- als auch auskommentierte Variablen nach der Verwendung von SIGHUP richtig erkannt bzw. ignoriert.

Eine weitere Sache: Welcher Wert wird genommen, wenn in der postgresql.conf eine Variable mehrfach gesetzt wurde?

Generell wird von oben nach unten gelesen, so dass der Wert von der am weitesten unten stehenden Variable verwendet wird.

Variablen können unter anderem auch einzeln für Rollen sowie Sessions gesetzt werden.

Finally, I made my talk/event plans for 2008.

This year I offer the following talks:

1. Take care of encoding (up to 1h) (either PostgreSQL or MySQL based)
2. Code review or what is bottom up verification? (up to 1h)
3. Take care of SQL injections (up to 1h) (either MySQL or PostgreSQL based)
4. How to make proper programming code (up to 1h)
5. What can you do for PostgreSQL community? (up to 30 minutes)
6. What is the PostgreSQL European group and it's history (up to 30 minutes)
7. Database design and SQL (up to 5 days)
8. Programming C (up to 5 days)
9. Programming Ruby (up to 3 days)

Of course I also can do the following talks from 2007 and earlier again:

1. PostgreSQL versus MySQL (I have overworked this talk) (up to 1h)
2. Performance tuning and optimisation of your SQL code (up to 30 minutes)
3. PostgreSQL workshop (up to 3h)

If you have a nice idea for a talk topic which isn't in my list, please don't be to shy to ask me.

My planed events for 2008:

1. Feb, 23rd-24th: FOSDEM, Brussels (it was a great event)
2. May, 20th-23rd: PGCon, Ottawa
3. Augst 23rd-24th FrOSCon, St. Augustin (internal PostgreSQL shortcut: "Bonn")
4. August 25th - September 5th: Informatica Feminale, University of Bremen
5. October (exact date isn't scheduled at the moment): PGDay Italy, Prato Toscana
6. November, 15th-16th, Come 2 Linux, Essen
7. 2009 Feb,: FOSEDEM, Brussels

I am thinking about the following events too but at the moment I am not sure if I'll visit them or not:

1. April, 26th-27th, PHP Unconference, Hamburg
2. May, 28th-31st, LinuxTag, Berlin

FOSDEM 2008 at Brussels wasn't great it was much more then great.

I am very proud of PostgreSQL. I have never seen such a big PostgreSQL booth and never seen so much PostgreSQL guys at the same place (besides PGDay Italy of course).

Also I never did so less booth work then this year at FOSDEM. There were so many other PostgreSQL guys that it wasn't necessary that I will be behind the booth.

Because I didn't have to take care of the booth I could join several talks. I heard a lot of talks.

My own two talks were great too.

Unfortunately the organisation made a misstake and they scheduled my "encoding/libc" talk at the same in the same room as two other talks.

I got another room and another time for my talk.

My "encoding/libc" talk wasn't announced very well but that doesn't matter. Only a quarter of the chairs of the room were empty. I got lots of interesting questions during and after this talk.

I will look, that I find a place, where I can offer the slides because there was no camera at the room.

There was no free chair at my other talk: "What can you do for PostgreSQL community". I was surprised about that.

Instead of constructive questions about activities at the PostgreSQL community I got lots of MySQL comparing questions. Of course, here it was the right address to ask me.

There should be a MySQL and PostgreSQL comparing talk too. I wanted to hear it to make sure that nothing goes wrong. Nobody knew the speaker and at least the speaker canceled.
We are sure, he didn't speak about his talk with PostgreSQL or MySQL before FOSDEM.

Also it was the first PostgreSQL booth I ever saw where MySQL guys visited us. I am pretty sure, they all agree with me, that the PostgreSQL guys were very open and friendly to them and that there is no competition. It was really nice to see a MySQL guy wearing a MySQL shirt with PostgreSQL buttons.

PostgreSQL, Debian, BSD and a few others have were in another building. We kidded: "wow, we are so prominent, that we got a own building". The result was, that the group of visitors were very geek like. The usual visitors often didn't reach the other building.

The positive result was: At the PostgreSQL booth we didn't get the question: "What's the different to MySQL" so often. Also we didn't get so many MySQL question as we usually get when there was no MySQL booth at an event (they didn't have had a booth at FOSDEM).

The other advantage was, that we were very close to the developer rooms.

Of course, I made a little experiment with my gender too. It was really funny. Because I got new hardware the week before FOSDEM I needed installation CDs/DVDs. I was too lazy to download them.

I went to the OpenSolaris booth inkognito and asked for a DVD. Of course the guy was really gentle and helpful. I think it happens not often that a woman is interested in OpenSolaris. When I told the guy I need gcc and all this typical programming stuff his face was surprised. I was really amazing to see this face

A few hours later Simon Phipps introduced me to this guy and he said: "hey, why didn't you say who you are? I wouldn't be so surprised about a woman that has interest in OpenSolaris and also seems to have knowledge about C programming if I have had known who you are"

Also FOSDEM was the first birthday of the PostgreSQL European group. We started the founding last year at FOSDEM and it was leaded during the first year by Andreas Scherbaum, Magnus Hagander, Dave Page and me.

This year we made an official election of the board of directors for the PostgreSQL European group. We needed to do it mainly because of all this donation laws.

The new four directors are: Magnus Hagandar (Sweden), Gabriele Bartolini (Italy), Jean-Paul Agudo (France) and Andreas Scherbaum (Germany).

Gabriele Bartolini announced, that there will be a PGDay 2008 in Prato (Italy) in October. We will hope, that this will get a as big success as last year.

And of course we are looking forward to FOSDEM 2009.

Lots of people asked me about "SUN aquires MySQL" and what does it mean for the "PostgreSQL guy, who is working for MySQL"?

Thanks to German laws, at the first view, for me this just means: "My company will get a new name".

We are doing business as usual at the moment and I don't expect big changes for developers and support team.

What does it mean for me? (Besides having some more advantages as employee, because the German SUN company is bigger and has more employee organisation stuff)

I am glad about it.
For my person, this was the best, what could happen.

I often got the question: "Will you now work for PostgreSQL again?"
Sorry, but did I ever stop "working" for PostgreSQL?

Ok, I was a little bit quieter during the last months. But this wasn't because I work for MySQL. This was, because I wasn't workless anymore and I got a new boyfriend. I just didn't have so much time to do so much.
It doesn't matter which kind of job I got, the same would happen with any other job too. I think, it is usual, that there are periods at your job and in your life, where you don't have time for anthing  else.

That there will be PostgreSQL and MySQL at the same company is great. With SUN, I got a senior brother for the fight against unpleasant users competition.

And I am the living example, that this works.

I'll hope, that all this ugly questions will stop:
For example: "Why can you work for MySQL as PostgreSQL guy?", "Why do you make a PostgreSQL talk as MySQL employee?".

Often I hear: "You are closer to Josh Berkus now!"
Am I? We both didn't move. For me, he is still living at the other side of the world.

Maybe, Josh and me will get one or more additional common communication base. But I already have lots of common communication bases with Josh. We both know our email addresses, we know, where we can find each other on IRC or on Skype and so on.

Of course, I am really glad, that Josh will get my colleague. I never dared even dreaming about this.

Its too early, to make big future plans.

Also every future plan, that I ever made, failed at the past.
For example: I wanted to have 10^7 Euro until I will get 35 (I never reached only a hundredth of this).
Since I live in Aachen (2005), I plan to go to Paris on a free weekend ... I still never was in Paris.
I am a burned child with lots of more serious future plans as well.

The future, I can see at the moment is:
That I will work further on as Support Engineer at MySQL. I really like my job.

Also my boyfriend is not so new anymore and I got a control over myself to the topic "work time and free time". It's not easy during the first month, to control your time, when you are working from home.

So, I can see, that I will have more time again, that I can spend on PostgreSQL.

My experience from events in 2007 is: It doesn't matter if I visit the event and make a PostgreSQL or a MySQL talk, the visitors always saw me as an agent for both. I always got questions for both systems.

And most times, nobody cares, that I work as PostgreSQL guy for MySQL (the ugly questions, that I wrote above, always were rarly).

Looking back to SUN: I often got this questions:
"Will MySQL finally get the PostgreSQL storage engine?"
Answer: Will a Ford car ever get the gear from BMW?

I am really looking forward to get a SUN employee. I'll take by surprise what will happening at the future.