Fonction PostgreSQL : est-ce un bogue ?Salut,
J'ai un problème avec les requêtes sur une base de données PostgreSQL utilisant le générateur de requêtes JMP...
En effet certaines fonctions PostgreSQL semblent ne pas fonctionner correctement dans le générateur de requêtes...
Par exemple, si je veux récupérer une partie d'une chaîne à partir de la position de l'un des caractères :
cette commande pourrait être écrite en PostgreSQL :
SÉLECTIONNER sous-chaîne ("Thomas" de position ('h' dans 'Thomas') pour 2) COMME bug_test
Mais si je l'écris dans "ajouter une colonne calculée" dans le générateur de requêtes JMP avec l'éditeur de formule SQL :
substring('Thomas' from position('h' in 'Thomas') for 2)J'obtiens cette erreur :
alors que cette même commande est bien exécutée si je l'écris à la main en SQL Custom :
Et dans ce cas, il est traduit en jsl comme les autres commandes SQL...
Ce que je ne comprends pas, c'est que je peux parfois écrire des formules complexes dans les "colonnes calculées" du constructeur de requêtes qui sont en pure syntaxe PostgreSQL et tout fonctionne bien! Comme:
Cette colonne calculée fonctionne correctement et ne renvoie aucun message d'erreur. Il s'agit cependant d'un code postgresql spécifique...
Est-ce un bogue connu sur certaines fonctions PostgreSQL ? Comment contourner le problème ?
Merci pour ton aide!
Franck
ScriptRe : Fonction PostgreSQL : est-ce un bug ?Bonjour Brian
Merci pour votre réponse
Ce qui est étrange pour moi, c'est que par exemple les fonctions "lpad" ou "to char" sont une syntaxe spécifique de PostgreSQL, pas du SQL générique ou du SQL Oracle,... et fonctionnent très bien :
t2.lot_id || '-' || lpad(to_char(t2.wafer_nr, 'FM999'), 2, '0')
Re : Fonction PostgreSQL : est-ce un bug ?Ajouter une colonne calculée a une liste de certaines extensions qu'il prendra en charge pour le SQL spécifique à la base de données, mais postgresql n'en fait pas partie.Par défaut, vous obtenez probablement SQL générique dans la liste déroulante en haut à gauche de l'éditeur de formule.Certaines extensions sont prises en charge pour Oracle, MySQL, SQL Server, SAS, etc.
Nous devrons envisager un ensemble d'extensions spécifiques à postgresql pour une future version de JMP.
Brian Corcoran
Développement JMP
