J'ai eu le plaisir de réaliser une présentation intitulée « The Need for Speed » dans laquelle on replace l'effort d'optimisation dans son contexte métier, afin de faire une étude des coûts et bénéfices et de savoir non seulement à quoi s'attendre mais aussi quand s'arrêter.

Merci à dalibo pour cette conférence !

L'idée de ma présentation, que la plupart d'entre vous a loupé je suppose (en tout cas je n'avais qu'une petite poignée de français dans la salle, et j'espère avoir des lecteurs qui n'étaient pas à Amsterdam), l'idée est d'utiliser les mécanismes offerts par les extensions afin de maintenir le code PL que vous utilisez en production.

Il s'agit la plupart du temps de procédures qui implémentent une partie de la logique métier de vos applications, mais si proche des données que cela termine en base directement : c'est une bonne chose, en particulier depuis PostgreSQL 9.1. Cette version propose en effet une gestion assez complète des extensions.

Il s'agit de réaliser un empaquetage de vos procédures en suivant la documentation en ligne et son chapitre 35.15. Empaqueter des objets dans une extension. Une fois cela fait, il est alors possible de déployer votre ensemble de procédure stockée avec la commande CREATE EXTENSION mesprocs;, et ensuite la commande psql \dx vous permet de lister les extensions installées et leur numéro de version.

Les mises à jours sont également gérées avec une commande SQL dédiée, il s'agit alors de ALTER EXTENSION mesprocs UPDATE [TO version];. Il suffit de fournir des scripts intermédiaires nommés par exemple mesprocs--1.0--1.1.sql et mesprocs--1.1--1.2.sql et PostgreSQL saura comment passer de 1.0 à 1.1.

Voilà, vous savez presque tout de ma présentation à Amsterdam et vous pouvez retrouver le reste sur le support proposé en début d'article. Bien sûr je n'ai pas reproduit ici les questions intéressantes qui m'ont été posées, une bonne partie d'entre elles sont venues enrichir ma liste de Noël pour les extensions. Si vous voulez être sûr de trouver cela sous votre sapin, cependant, le meilleur moyen est encore de m'en parler : sponsoriser les développement Open Source est une belle démarche :)

Je présenterai donc comment utiliser les extensions, le titre en anglais est Extensions are good for business logic, et l'idée est de voir comment exploiter les extensions afin de mieux gérer vos mises à jours en bases de données.

Le cycle de vie des bases de données en production inclue souvent l'utilisation d'une base de développement où le schéma évolue au rythme des besoins des développeurs, et de temps en temps on consolide une partie de ces modifications (dans des rollouts, scripts contenant principalement des DDL) afin de les déployer en production — si possible avec une étape intermédiaire en préproduction, tout de même.

Savoir ce qui est déployé en développement et comment en retirer le script à jouer en production peut être parfois fastidieu. Quand ce n'est pas le cas, c'est que le travail a été fait en amont, ce qui est le signe d'une bonne organisation, avec les surcoûts que l'on peut imaginer.

Les extensions telles que présentes dans PostgreSQL 9.1 vous permettent de mieux gérer ce genre de cas, en optimisant le surcoût : il ne disparaît pas, mais devient opérationnel plutôt que de rester une charge d'organisation.

Allez, je vous laisse maintenant, je dois me préparer pour la conférence :)

C'est l'endroit où aller pour apprendre comment le projet fonctionne, comprendre les impacts des nouvelles versions sur votre architecture, avoir une discussion technique pointue sur cette fonctionalité que vous voudriez voir arriver dans la prochaine version, ou simplement vous rendre compte de l'énergie formidable qui est insuflée dans ce projet !

Évidemment 2ndQuadrant sera de la partie, nous présenterons plusieurs de nos contributions PostgreSQL 9.1. Cela commencera avec la formation d'une journée complète de Greg, Performance From Start to Crash : si vous voulez apprendre comment aborder les performances d'un serveur PostgreSQL par le leader international du domaine, auteur du livre Bases de données PostgreSQL 9.0, réservez vite votre place !

Les présentation au format classique commencent le lendemain, et en trois jours la liste des présentation de notre équipe 2ndQuadrant est assez copieuse. Voyons cela.

Nous commençons avec Migration to PostgreSQL - a holistic view par Harald Armin Massa, qui propose un point de vue intéressant sur les raisons qui retiennent certaines migrations. Ensuite Gianni Ciolli présentera Look Out The Window Functions (and free your SQL) ou comment résoudre simplement des problèmes complexes lorsque l'on dispose d'outils avancés.

Une autre présentation à ne pas rater, Synchronous Replication and Durability Tuning détaille comment profiter au mieux de PostgreSQL 9.1 afin d'obtenir les garanties de durabilité des données souhaitées dans votre application. Et cette présentation est animée par Greg Smith et Simon Riggs. Ce dernier a développé la réplication synchrone, et Hot Standby avant cela. Vous ne trouverez personne au monde mieux placé pour faire cette présentation !

Les deux prochaines présentation de nos experts PostgreSQL, en continuant notre lecture du programme de pgconf.eu dans l'ordre, ont lieu au même moment. Le choix ne sera pas facile entre Improving VACUUM Suction par Greg à nouveau, et une comparaison de londiste 3 et slony 2.1 par Cédric Villemain, en français.

À suivre, Extensions are good for business logic que je vous présenterai moi-même, vous pouvez voir ma présentation sur la fiche qui porte mon nom : Dimitri Fontaine. Il s'agit d'une présentation en anglais qui détaille comment utiliser les extensions dans le cadre de la maintenance de la partie procédures stockées d'une application.

Et pour finir le deuxième jour des conférences 2ndQuadrant, vous pourrez apprendre avec Gianni comment Debugging complex SQL queries with writable CTEs, une fonctionnalité contribuée au projet par un autre consultant 2ndQuadrant, Marko Tiikkaja.

Et il reste encore une journée ! Nous ne mentons pas en disant que le programme est complet ! Le dernier jour de la conférence n'est pas le moins intéressant, j'espère que vous aurez su garder un peu d'énergie pour suivre…

Simon Riggs qui présentera sa vision de la PostgreSQL Roadmap pour les prochaines années. Ce n'est bien sûr que sa vision personnelle, mais lorsque l'on fait le bilan de ces 7 dernières années de contributions à PostgreSQL, on voit à quel point son opinion personnelle peut avoir du poids dans le développement du projet.

À suivre, la présentation de Greg sur son sujet de prédilection : Bottom-up Database Benchmarking. Tout ce que vous avez toujours voulu savoir sur les mesures de performances de vos bases de données, sans jamais oser le demander. Quelque chose dans ce style en tout cas :)

Bien sûr d'autres présentations sont disponibles et retiendront votre attention, ce billet vous présente seulement celles qui seront données par les experts PostgreSQL de 2ndQuadrant. En vous souhaitant bonne conférence à tous, j'espère avoir le plaisir de vous retrouver à Amsterdam le mois prochain !

Nous commençons à lire des articles qui reprennent la nouvelle dans la presse française, et j'ai le plaisir de mentionner celui de programmez.com qui annonce « un système d'extensions inégalé ». En tant que développeur des Extensions dans PostgreSQL, je ne peux qu'être non seulement d'accord avec eux, mais aussi flatté :)

Bons tests à tous, et bonne mises à jour pour les plus chanceux !

Nous faisons face ici à un problème de sécurité très bien décrit dans le billet humoristique de Little Boby Tables, dont je vous recommande la lecture. L'idée est simple, la mise en place de contre mesure fourmille de pièges subtils, à moins d'utiliser la solution décrite ci-après.

Lorsque l'on envoie une requête SQL à PostgreSQL, celle-ci contient pêle-mêle un mélange de mots-clés SQL et de données utilisateurs. Dans la requête SELECT colname FROM table WHERE pk = 1234; l'élément 1234 est une donnée fournie à PostgreSQL. Lorsque l'on utilise d'autre types de données, on va parler de litéral, qui peut être ou non décoré. Un exemple ?

=# SELECT 'undecorated literal', pg_typeof('undecoreted literal'),
          date 'today', pg_typeof(date 'today');
      ?column?       | pg_typeof |    date    | pg_typeof
---------------------+-----------+------------+-----------
 undecorated literal | unknown   | 2011-09-07 | date
(1 row)

Outre l'aspect types de données (un litéral non décoré est de type unknown jusqu'à ce qu'une opération force son type, c'est ce qui permet d'avoir du polymorphisme dans PostgreSQL), nous voyons ici que PostgreSQL doit faire la différence entre le SQL lui-même et les paramètres qui le composent. Il sait bien sûr faire cela, il suffit d'encadrer les valeurs dans des simples guillemets ou bien d'utiliser la notation dite de dollar quoting. Mais si l'on ne prend pas de précautions, l'utilisateur peut terminer la séquence d'échappements depuis le champ de saisie du formulaire…

libpq est la librairie standard cliente de PostgreSQL et fourni des API de connexion et propose une fonction PGexecParams. Cette fonction expose un mécanisme disponible dans le protocole de communication de PostgreSQL lui-même : il est possible de faire parvenir le SQL et les données qu'il contient dans deux parties différentes du messages plutôt que de les mélanger. Ainsi, le serveur n'a plus du tout à deviner où commencent et où terminent les données dans la requête, il lui suffit de regarder dans le tableau séparé contenant les données quand il en a besoin.

Terminées les injections SQL !

Note : cette fonction est exposée dans la plupart des pilotes de connexion, et même en PHP, dont la popularité et l'exposition me poussent à donner une référence plus précise : utilisez pg_query_params, son intérêt n'est pas simplement syntaxique, il va jusque dans la définition des échanges de données entre le client (votre code PHP) et le serveur (PostgreSQL).

En effet, l'utilisation d'échappements avec le caractère « anti-slash » n'est pas conforme au standard SQL. Le paramètre standard_conforming_strings permet de contrôler le comportement de PostgreSQL lorsqu'il lit une chaîne de caractère dans une requête SQL.

Voyons quelques exemples :

dimitri=# set standard_conforming_strings to true;
SET
dimitri=# select 'hop''';
 ?column?
----------
 hop'
(1 ligne)

dimitri=# select 'hop\'';
dimitri'# ';
 ?column?
----------
 hop\';

(1 ligne)

dimitri=# select E'hop\'';
 ?column?
----------
 hop'
(1 ligne)

dimitri=# set standard_conforming_strings to false;
SET
dimitri=# select E'hop\'';
 ?column?
----------
 hop'
(1 ligne)

dimitri=# select 'hop\'';
ATTENTION:  utilisation non standard de \' dans une chaîne littérale
LIGNE 1 : select 'hop\'';
                 ^
ASTUCE : Utilisez '' pour écrire des guillemets dans une chaîne ou utilisez
la syntaxe de chaîne d'échappement (E'...').
 ?column?
----------
 hop'
(1 ligne)

Il existe un moyen de forcer PostgreSQL à accepter l'utilisation d'échappements avec « anti-slash » indépendamment de la valeur de standard_conforming_strings, c'est la notation préfixée avec E. Il est recommandé de toujours l'utiliser dès lors que la chaîne de caractère contient des « anti-slash » utilisés comme échappement (du caractère simple guillemet en général).

Le paramètre escape_string_warning, enfin, permet de désactiver les avertissements tels que présentés dans le dernier exemple ci-dessus, lorsqu'il est positionné à off. Bien sûr, sa valeur par défaut est on.

Toute apparition de ce WARNING lorsque escape_string_warning est on signifie que votre application n'est pas prête à migrer à 9.1 avec son paramétrage par défaut. Il existe deux actions possible : changer le paramétrage de sa nouvelle valeur par défaut à sa précédente, ou bien corriger ses applications pour utiliser le préfixe E dès que cela est nécessaire.

L'utilisation de standard_conforming_strings à on présente un autre avantage au respect du standard SQL : la sécurité contre les injections. S'il n'est pas possible d'échapper le guillemet simple qui termine toute chaîne de caractère utilisateur, il devient compliqué de jouer au plus malin avec le parser. Le mieux ici reste bien sûr d'utiliser les requêtes paramétrées, à suivre dans un prochain article.

En effet, l'utilisation d'échappements avec le caractère « anti-slash » n'est pas conforme au standard SQL. Le paramètre standard_conforming_strings permet de contrôler le comportement de PostgreSQL lorsqu'il lit une chaîne de caractère dans une requête SQL.

Voyons quelques exemples :

dimitri=# set standard_conforming_strings to true;
SET
dimitri=# select 'hop''';
 ?column?
----------
 hop'
(1 ligne)

dimitri=# select 'hop\'';
dimitri'# ';
 ?column?
----------
 hop\';

(1 ligne)

dimitri=# select E'hop\'';
 ?column?
----------
 hop'
(1 ligne)

dimitri=# set standard_conforming_strings to false;
SET
dimitri=# select E'hop\'';
 ?column?
----------
 hop'
(1 ligne)

dimitri=# select 'hop\'';
ATTENTION:  utilisation non standard de \' dans une chaîne littérale
LIGNE 1 : select 'hop\'';
                 ^
ASTUCE : Utilisez '' pour écrire des guillemets dans une chaîne ou utilisez
la syntaxe de chaîne d'échappement (E'...').
 ?column?
----------
 hop'
(1 ligne)

Il existe un moyen de forcer PostgreSQL à accepter l'utilisation d'échappements avec « anti-slash » indépendamment de la valeur de standard_conforming_strings, c'est la notation préfixée avec E. Il est recommandé de toujours l'utiliser dès lors que la chaîne de caractère contient des « anti-slash » utilisés comme échappement (du caractère simple guillemet en général).

Le paramètre escape_string_warning, enfin, permet de désactiver les avertissements tels que présentés dans le dernier exemple ci-dessus, lorsqu'il est positionné à off. Bien sûr, sa valeur par défaut est on.

Toute apparition de ce WARNING lorsque escape_string_warning est on signifie que votre application n'est pas prête à migrer à 9.1 avec son paramétrage par défaut. Il existe deux actions possible : changer le paramétrage de sa nouvelle valeur par défaut à sa précédente, ou bien corriger ses applications pour utiliser le préfixe E dès que cela est nécessaire.

L'utilisation de standard_conforming_strings à on présente un autre avantage au respect du standard SQL : la sécurité contre les injections. S'il n'est pas possible d'échapper le guillemet simple qui termine toute chaîne de caractère utilisateur, il devient compliqué de jouer au plus malin avec le parser. Le mieux ici reste bien sûr d'utiliser les requêtes paramétrées, à suivre dans un prochain article.

L'ensemble des articles de cette série permettra de constituer un tutoriel pgloader plus étoffé que l'actuel. Si vous êtes intéressés par une version française, un mail de votre part justifierait l'effort que cela représente !

Bonne lecture !

En attendant, bonne lecture !

Les slides de l'ensemble des présentations devraient être publiés en ligne à terme, mais cela ne va pas pouvoir être fait aussi rapidement que nous le voudrions tous. Alors voici un peu de lecture en attendant la suite !