Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner 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 les nommer tous UDFs à l'aide du préfixe`f_`. Amazon Redshift réserve le `f_` préfixe exclusivement pour UDFs et en préfixant vos noms UDF avec`f_`, 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\$1catalog, 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\$1catalog 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\$1catalog à 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](r_SET.md) et [search\$1path](r_search_path.md).