La plupart des postes de développeur PL/pgSQL naissent d'une sortie d'Oracle. L'entreprise veut réduire ses coûts de licence ou passer sur un service managé comme Amazon RDS, Aurora ou Azure Database for PostgreSQL. Il faut alors convertir des centaines de procédures, de packages et de triggers, les tester, puis maintenir le code dans PostgreSQL. D'autres postes, plus rares, concernent des applications construites dès le départ sur PostgreSQL, avec de la logique métier dans la base.
Le risque principal vient des profils Oracle qui pensent que la conversion est surtout une affaire de syntaxe. Ora2Pg fait une bonne partie du travail mécanique. Les écarts de comportement restent à traiter à la main : pas de packages, la chaîne vide distincte de NULL, des règles de COMMIT différentes dans les procédures, aucune transaction autonome, un bloc EXCEPTION qui coûte une sous-transaction. Un bon candidat les connaît et sait les repérer dans un code existant.
Un bon exercice consiste à montrer au candidat une procédure Oracle courte, avec un package et un COMMIT au milieu, et à lui faire dire ce qui changera dans PostgreSQL. Le PDF contient un cas de 20 minutes sur la migration d'un calcul de factures.
PostgreSQL, Ora2Pg et les outils du poste
PL/pgSQL
Le langage procédural de PostgreSQL, proche du PL/SQL dans sa syntaxe. On y écrit des fonctions, des procédures (depuis PostgreSQL 11) et des fonctions trigger. Les ressemblances avec Oracle cachent des différences de comportement : c'est là que l'entretien doit insister.
PostgreSQL
La base open source qui reçoit la plupart des migrations depuis Oracle. Une version majeure sort chaque année. Un développeur à jour sait quelle version tourne chez vous et ce qu'elle permet, par exemple MERGE, disponible depuis PostgreSQL 15.
Ora2Pg
L'outil libre de référence pour migrer d'Oracle vers PostgreSQL. Il produit un rapport d'évaluation de la charge, puis exporte le schéma, les données et le code PL/SQL converti. Le code généré demande toujours une relecture et des tests.
orafce
Une extension qui ajoute à PostgreSQL des fonctions et des paquets compatibles Oracle (DECODE, NVL, certaines fonctions de dates et de chaînes). Elle accélère une migration, au prix d'une dépendance à vérifier sur le service managé visé.
EXPLAIN ANALYZE et pg_stat_statements
EXPLAIN ANALYZE exécute la requête et affiche le plan réel avec les durées et les lignes lues. pg_stat_statements cumule les statistiques de toutes les requêtes pour trouver celles qui coûtent le plus. Les deux servent à corriger les régressions après une migration.
Services managés PostgreSQL
Amazon RDS et Aurora PostgreSQL, Azure Database for PostgreSQL, Cloud SQL chez Google. Pas de superutilisateur, une liste fermée d'extensions, pas d'accès aux fichiers du serveur. Ces limites changent les solutions possibles pour convertir certains traitements Oracle.
pgTAP et outils de livraison
pgTAP écrit des tests unitaires en SQL, lancés dans la CI. Flyway, Liquibase ou Sqitch appliquent les scripts de schéma dans l'ordre et gardent l'historique. psql, DBeaver et pgAdmin servent au quotidien.
Le poste dépend de l'avancement du projet. En début de migration, la personne lit le code Oracle, estime la charge avec Ora2Pg et convertit les objets un par un. En fin de migration, elle traite les régressions de performance et les écarts de résultats trouvés en recette. Après la bascule, elle maintient et fait évoluer le code PL/pgSQL. Les ESN recrutent beaucoup ce profil pour des programmes de sortie d'Oracle chez des grands comptes et dans le secteur public. Un DBA PostgreSQL gère en parallèle la réplication, les sauvegardes et la haute disponibilité. Il n'existe pas de certification officielle du projet PostgreSQL, celles des éditeurs restent secondaires face à une migration menée.
Ce qu'un développeur PL/pgSQL doit maîtriser
- Fonctions, procédures et triggers PL/pgSQL
- Conversion du PL/SQL Oracle
- Différences de types et de comportement Oracle et PostgreSQL
- Lecture des plans avec EXPLAIN ANALYZE
- Transactions et concurrence dans PostgreSQL
- Migration outillée et tests de non-régression
Cinq questions sur le passage d'Oracle à PostgreSQL
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Vous devez porter un package Oracle avec des procédures publiques, des procédures privées et des variables globales. Comment l'organisez-vous dans PostgreSQL ?
Une bonne réponsePostgreSQL n'a pas de packages. Un schéma par package regroupe les fonctions et procédures, avec des droits EXECUTE donnés seulement sur celles qui étaient publiques et retirés à PUBLIC sur les autres. Les variables globales de session deviennent des paramètres personnalisés lus avec current_setting et écrits avec set_config, ou une table temporaire. Les constantes deviennent des fonctions IMMUTABLE. Il sait que les packages existent dans EDB Postgres Advanced Server, pas dans PostgreSQL standard.
Signal d'alerteTout créer dans le schéma public avec des noms préfixés, sans gérer les droits, ou supposer que l'état d'une variable de package se retrouve tout seul dans PostgreSQL.
Question 2 · confirmé
Après migration, un contrôle WHERE commentaire IS NULL ne ramène plus les mêmes lignes qu'avant. Pourquoi ?
Une bonne réponseOracle traite la chaîne vide comme NULL, PostgreSQL non. Les lignes migrées avec '' ne sont plus nulles. Même écart sur la concaténation : dans Oracle, 'a' || NULL donne 'a', dans PostgreSQL le résultat est NULL, sauf avec la fonction concat(). Il propose un audit des colonnes concernées, une conversion avec NULLIF(col, '') au chargement si la règle métier le veut, et une revue des NVL devenus COALESCE.
Signal d'alerteNe pas connaître la différence entre chaîne vide et NULL dans les deux bases, ou la découvrir en recette par les utilisateurs.
Question 3 · senior
Une procédure Oracle fait un COMMIT toutes les 10 000 lignes et écrit ses erreurs dans un journal en transaction autonome. Comment la portez-vous ?
Une bonne réponseDepuis PostgreSQL 11, une procédure appelée par CALL peut faire COMMIT et ROLLBACK, ce qu'une fonction ne peut pas. Deux limites : l'appel ne doit pas venir d'une transaction ouverte par l'appelant, et on ne peut pas terminer la transaction à l'intérieur d'un bloc qui a une clause EXCEPTION. PostgreSQL n'a pas de transaction autonome : le journal passe par dblink ou l'extension pg_background, ou par une écriture faite après le rollback, ou par les logs du serveur avec RAISE.
Signal d'alerteMettre un COMMIT dans une fonction, ou supposer que PRAGMA AUTONOMOUS_TRANSACTION existe sous un autre nom.
Question 4 · confirmé
Une requête qui prenait deux secondes sous Oracle en prend quarante après migration. Comment cherchez-vous la cause ?
Une bonne réponseEXPLAIN (ANALYZE, BUFFERS) pour le plan réel, en comparant lignes estimées et lignes réelles à chaque nœud. Il vérifie que les tables ont été analysées après le chargement (ANALYZE), sinon l'optimiseur n'a aucune statistique. Puis les types : un NUMBER converti en numeric, joint à une colonne en bigint, ou une conversion qui empêche l'utilisation d'un index. Les hints Oracle restés en commentaire n'ont aucun effet, sauf avec l'extension pg_hint_plan.
Signal d'alerteAugmenter la mémoire du serveur sans lire le plan, ou s'étonner que les hints Oracle ne fonctionnent plus.
Question 5 · senior
Le code converti entoure chaque ligne d'un traitement d'un bloc BEGIN ... EXCEPTION pour reproduire un WHEN OTHERS. Qu'en pensez-vous sur un million de lignes ?
Une bonne réponseChaque bloc avec une clause EXCEPTION ouvre une sous-transaction, un point de sauvegarde, ce qui coûte cher en boucle et consomme des identifiants de transaction. En cas d'erreur, toutes les modifications du bloc sont annulées. Il préfère valider les données en SQL avant le traitement, isoler les lignes en erreur par une requête, et réserver le bloc EXCEPTION aux cas utiles. Il connaît GET STACKED DIAGNOSTICS et RAISE EXCEPTION avec un ERRCODE.
Signal d'alerteReproduire la structure Oracle ligne pour ligne sans savoir qu'un bloc EXCEPTION a un coût dans PostgreSQL.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Recruter pour une migration Oracle vers PostgreSQL
Un développeur PL/SQL Oracle peut-il tenir ce poste ?
Oui, à condition qu'il connaisse les écarts entre les deux bases et ne se limite pas à la syntaxe. Sa connaissance du code Oracle d'origine est un atout pour comprendre ce que chaque procédure doit produire. Vérifiez qu'il sait ce que deviennent les packages, les transactions autonomes et la chaîne vide, et qu'il a déjà lu un plan avec EXPLAIN ANALYZE. Sans pratique de PostgreSQL, prévoyez un temps de prise en main.
Développeur PL/pgSQL ou DBA PostgreSQL pour une migration ?
Les deux, en général. Le DBA prépare l'infrastructure, la réplication, les sauvegardes, le réglage du serveur et souvent le transfert des données. Le développeur convertit le code, le teste et corrige les écarts de résultat. Sur un petit périmètre, un seul profil peut couvrir les deux. Au-delà de quelques centaines d'objets PL/SQL, séparer les rôles évite que la conversion du code passe après l'exploitation.
Quel exercice proposer en test technique ?
Une procédure Oracle courte à convertir pendant l'entretien, qui contient quelques pièges : un NVL sur une chaîne qui peut être vide, un COMMIT dans une boucle, un WHEN OTHERS et une variable de package. Ajoutez un plan EXPLAIN ANALYZE à commenter. En vingt minutes, vous voyez si la personne repère les écarts de comportement ou si elle traduit mot à mot.
Faut-il connaître EDB Postgres Advanced Server ?
Seulement si l'entreprise l'utilise. EDB Postgres Advanced Server est une distribution commerciale de PostgreSQL qui ajoute une compatibilité Oracle, avec les packages et une syntaxe proche du PL/SQL. Elle réduit la charge de conversion mais crée une dépendance à un éditeur. Sur un PostgreSQL standard ou un service managé, ces facilités n'existent pas et le code doit être réécrit.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
