Amazon Redshift ne prendra plus en charge la création de nouveaux UDFs Python à partir du patch 198. Les fonctions Python définies par l’utilisateur existantes continueront de fonctionner normalement jusqu’au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
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](r_CREATE_FUNCTION.md).
## Éviter les conflits avec les fonctions intégrées d’Amazon Redshift
Nous vous recommandons de nommer toutes les fonctions UDF en utilisant le préfixe `f_`. Amazon Redshift réserve le préfixe `f_` exclusivement aux fonctions UDF et si vous ajoutez aux noms de vos fonctions UDF le préfixe `f_`, vous vous assurez que le nom de votre fonction UDF n'entrera pas en conflit avec n'importe quelle fonction SQL intégrée Amazon Redshift existante ou à venir. 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. Si vous le faites, vos fonctions UDF sont prioritaires par rapport aux 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](r_SET.md) et [search\_path](r_search_path.md).