Il semble que pour le moment au moins, la définition de search_path est quelque chose hors de portée pour jOOQ. Nous pourrions, en théorie, utiliser les migrations Java dans Flyway et forcer toutes les références d'une fonction à avoir des schémas explicites, mais cela semble assez pénible. Ce qui nous laisse soit définir le chemin de recherche manuellement, éventuellement l'ajouter à notre gestion des transactions, soit écrire un ConnectionProvider plus intelligent.
Nous avons un modèle assez strict d'une requête par transaction sur notre application, il n'y a donc pas vraiment de gestion des transactions en place pour ajouter la requête "set search_path =...". La solution ConnectionProvider semble être notre meilleure option.
Nous avons déjà une implémentation personnalisée de ConnectionProvider pour le regroupement de connexions, il n'était donc pas trop compliqué d'ajouter la logique (donnée ci-dessus à la fin de la question) pour définir le search_path. Nous pourrions le rendre plus performant en décorant la connexion avec quelque chose qui se souvient de la valeur de son search_path actuel et en préfixant un "set search_path =...;" au début de tout relevé avant qu'il ne sorte, si nécessaire. Nous constatons déjà un impact sur les performances lors de la définition du search_path à chaque requête, ce n'est donc qu'une question de temps avant que cela ne devienne une nécessité. Eh bien, cela ou revenir à la douleur de notre ancienne couche d'accès à la base de données propriétaire.
À tout le moins, je n'accepterai pas cela comme réponse jusqu'à ce que j'écrive et ouvre le paramètre ConnectionProvider de pooling/search_path ConnectionProvider, dans l'espoir que quelqu'un d'autre trouvera une meilleure solution avant que je ne m'y mette.
