BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités PostgreSQL 14 Casse Les Pilotes .NET Et Java Pour PostgreSQL

PostgreSQL 14 Casse Les Pilotes .NET Et Java Pour PostgreSQL

Favoris

Dans certaines circonstances, la nouvelle syntaxe de PostgreSQL 14 cassera son pilote de base de données .NET et Java officiel. Plus précisément, lors de l'utilisation de l'un ou l'autre pour créer une fonction SQL à l'aide de BEGIN ATOMIC... END. Si vous ne modifiez pas votre schéma de base de données via Npgsql ou PgJDBC, il n'y a pas lieu de s'inquiéter.

Les frameworks de pilote de base de données JDBC de Java et ADO.NET de .NET ont une caractéristique commune : ils prennent tous deux en charge les instructions SQL par lots à l'aide de points-virgules. Cela a été jugé nécessaire pour des raisons de performances. Si vous envoyez une commande à la fois, vous devez payer le coût de latence pour chaque commande. A l'inverse, en envoyant un lot vous n'avez à payer qu'une seule fois le coût.

Pour certaines bases de données telles que SQL Server, vous envoyez littéralement le lot entier sous la forme d'une chaîne SQL massive. Mais le format wire de PostgreSQL ne fonctionne pas de cette façon. Le client doit diviser le lot en commandes individuelles même si elles sont toujours envoyées sous forme d'ensemble.

L'implémentation naïve de ceci serait de simplement supposer que chaque point-virgule signifie la fin du lot. Bien sûr, il est possible qu'un point-virgule ne représente pas la fin d'une instruction, mais fasse simplement partie d'une chaîne littérale. Les analyseurs Npgsql et PgJDBC en tiennent compte.

Jusqu'ici tout va bien. Mais que se passe-t-il si vous définissez une nouvelle fonction SQL composée de plusieurs instructions ? Ce n'était toujours pas un problème car le corps de la fonction serait échappé à l'aide de dollars comme séparateurs. Tout point-virgule à l'intérieur de la paire de jetons $$ serait traité comme n'importe quel autre chaîne littérale.

Puis PostgreSQL 14 est arrivé et a ajouté BEGIN ATOMIC... END, également connue sous le nom de "syntaxe standard SQL". Les release notes disent,

Lors de l'écriture d'une fonction ou d'une procédure dans la syntaxe standard SQL, le corps est analysé immédiatement et stocké sous forme d'une arborescence suite à l'analyse. Cela permet un meilleur suivi des dépendances des fonctions et peut avoir des avantages en matière de sécurité.

Étant donné que les points-virgules peuvent apparaître n'importe où dans un bloc BEGIN ATOMIC... END, sans être dans une chaîne entre guillemets, les analyseurs ne peuvent pas utiliser l'approche actuelle pour déterminer où le lot doit être divisé en instructions. La prise en charge complète de cela nécessiterait soit un changement d'API, soit la construction d'un nouvel analyseur beaucoup plus complexe.

Comme ils étaient déjà préoccupés par la surcharge de traitement causée par l'analyseur actuel, le Npgsql a décidé de changer l'API. Ils ont ajouté ce qu'ils appellent un mode SQL brut à la bibliothèque. Ce mode nécessite également l'utilisation de paramètres positionnels au lieu de paramètres nommés.

L'équipe PgJDBC n'a pas décidé quelle approche adopter. Vous pouvez suivre leur progression dans le rapport de bug intitulé New PG14 SQL-standard function bodies break our SQL parser.

 

Au sujet de l’Auteur

Evaluer cet article

Pertinence
Style

Contenu Éducatif

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

BT