Extensions PostgreSQL dans EcoSQL (seconde partie)

EcoSQL augmente la liste des 29 extensions mises à disposition

Il s’agit ici de vous les présenter, retenez 2 points :

• EcoSQL n’a pas d’expertise dans le domaine de ces extensions
• les extensions présentées ici peuvent avoir des conditions de déploiements et d’usages spécifiques dans le cadre d’EcoSQL.

EcoSQL a travaillé sur 12 extensions seules 8 ont été retenues.

• anonymizer,
• dblink,
• postgres_fdw,
• pgrouting,
• pgvector,
• pg_squeeze,
• pg_stat_statements,
• timescaledb.

Quatre extensions ont été testées mais n’ont pas été retenues pour EcoSQL

Les extensions ci-dessous ne remplissent pas, à ce jour, les conditions pour être prises en charge par EcoSQL.
On vous explique pourquoi.

• 1° ogr_fdw
  Cette extension s’adresse principalement à des ressources internes système (écrire/lire sur la machine EcoSQL) ou à des ressources externes (internet).
  Pour des raisons de sécurité système et de flux, cette extension ne sera pas prise en charge par EcoSQL.

• 2° pg_repack
  Pour être utilisée, cette extension demande d’être installée également sur le poste client.
  Le service de réorganiser les tables est offert sur EcoSQL avec l’extension pg_squeeze, plus récente et identique en fonctionnalités, voir plus étendues que pg_repack.
  Seule l’extension pg_squeeze est retenue.

• 3° pg_stat_monitor
  L’extension pg_stat_monitor n’est pas si "libre".
  Elle est proposée en paquet Debian, elle demande pour être utilisée d’installer un moteur PostgreSQL spécifique et sous licence Percona.

• 4° pg_cron
  L’extension pg_cron pose plusieurs questions notamment de sécurité qui se cumulent :
  • Demande un role déclaré dans le pg_hba.conf avec un droit trust local pour exécuter le cron.
  • Par défaut, en EcoSQL, la déclaration de la base cible cron.database_name ne peut être autre que la base postgres qui est interdite à la connexion aux rôles applicatifs.
  • EcoSQL n’autorise pas non plus la relance d’une instance à ses utilisateurs, il n’est donc pas possible à un rôle non superutilisateur de changer et de prendre en compte une autre base que celle par défaut pour cron.database_name.
  • La fonction cron.schedule_in_database aurait pu permettre au rôle manager de se substituer à un rôle applicatif. Or la fonction cron.schedule_in_database est uniquement ouverte à un rôle de niveau superutilisateur, cela est écrit "en dur" dans le code C de l’extension pg_cron. Ce droit ne peut donc être redonné au rôle manager.

Vous avez besoin d’autres extensions PostgreSQL supplémentaires ?

EcoSQL vous invite à en discuter, les étudier et les intégrer sous conditions.

• Partagez le nom de l’extension avec le troupeau dans le salon Tchap #EcoSQL , préfixez votre conversation du mot [extension].
• Vous pouvez également déposez le nom de l’extension souhaitée via un formulaire de demande