Amazon Redshift ne prendra plus en charge la création de nouveaux Python UDFs à compter du 1er novembre 2025. Si vous souhaitez utiliser Python UDFs, créez la version UDFs antérieure à cette date. Le Python existant UDFs continuera à fonctionner normalement. Pour plus d'informations, consultez le billet de blog.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Prévention des conflits de dénomination des fonctions UDF

Vous pouvez éviter les conflits potentiels et les résultats inattendus en prenant garde à vos conventions de dénomination de fonctions UDF avant la mise en œuvre. Etant donné que les noms de fonctions peuvent être surchargés, ils peuvent entrer en conflit avec des noms de fonctions Amazon Redshift existants et à venir. Cette rubrique traite de la surcharge et propose une stratégie permettant d'éviter les conflits.

Surcharge des noms de fonctions

Une fonction est identifiée par son nom et sa signature, c'est-à-dire le nombre d'arguments d'entrée et les types de données des arguments. Deux fonctions d'un même schéma peuvent porter le même nom si elles ont des signatures différentes. Autrement dit, les noms des fonctions peuvent être surchargés.

Lorsque vous exécutez une requête, le moteur de requête détermine quelle fonction appeler en fonction du nombre d'arguments que vous fournissez et des types de données des arguments. Vous pouvez utiliser une surcharge pour simuler des fonctions avec un nombre d'arguments variable, jusqu'à la limite autorisée par la commande CREATE FUNCTION.

Éviter les conflits avec les fonctions intégrées d'Amazon Redshift

Nous vous recommandons de les nommer tous UDFs à l'aide du préfixef_. Amazon Redshift réserve le f_ préfixe exclusivement pour UDFs et en préfixant vos noms UDF avecf_, vous vous assurez que votre nom UDF n'entrera en conflit avec aucun nom de fonction SQL intégré Amazon Redshift existant ou futur. Par exemple, en nommant une nouvelle fonction UDF f_sum, vous évitez tout conflit avec la fonction SUM Amazon Redshift. De même, si vous nommez une nouvelle fonction f_fibonacci, vous évitez les conflits si Amazon Redshift ajoute une fonction nommée FIBONACCI dans une version ultérieure.

Vous pouvez créer une fonction UDF avec les mêmes nom et signature qu'une fonction SQL intégrée Amazon Redshift existant sans que le nom de la fonction soit surchargé si la fonction UDF et la fonction intégrée existent dans différents schémas. Etant donné qu'il existe des fonctions intégrées dans le schéma catalogue système, pg_catalog, vous pouvez créer une fonction UDF portant le même nom dans un autre schéma, comme un schéma public ou un schéma défini par l'utilisateur. Dans certains cas, vous pouvez appeler une fonction qui n'est pas explicitement qualifiée par un nom de schéma. Si c'est le cas, Amazon Redshift recherche d'abord le schéma pg_catalog par défaut. Ainsi, une fonction intégrée s'exécute avant une nouvelle fonction UDF portant le même nom.

Vous pouvez modifier ce comportement en définissant le chemin de recherche de manière à placer pg_catalog à la fin. Dans ce cas, vous aurez la UDFs priorité sur les fonctions intégrées, mais cette pratique peut entraîner des résultats inattendus. L'adoption d'une stratégie d'attribution de noms unique, par exemple en utilisant le préfixe réservé f_, est une pratique plus fiable. Pour plus d’informations, consultez SET et search_path.