Amazon Redshift non supporterà più la creazione di nuovi Python UDFs a partire dalla Patch 198. Python esistente UDFs continuerà a funzionare fino al 30 giugno 2026. Per ulteriori informazioni, consulta il [post del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Prevenzione dei conflitti di denominazione delle funzioni definite dall'utente
Puoi evitare possibili conflitti e risultati imprevisti valutando con attenzione le convenzioni di denominazione delle funzioni definite dall'utente prima dell'implementazione. Poiché i nomi delle funzioni possono essere soggetti a overload, possono entrare in conflitto con nomi di funzioni Amazon Redshift esistenti e future. Questo argomento descrive l'overload e presenta una strategia per evitare i conflitti.
## Overload dei nomi delle funzioni
Una funzione è identificata dal proprio nome e da una *firma*, che corrisponde al numero di argomenti di input e ai tipi di dati degli argomenti. Due funzioni nello stesso schema possono avere lo stesso nome se hanno firme diverse. In altri termini, i nomi delle funzioni possono essere in *overload*.
Quando si esegue una query, il motore di query determina quale funzione chiamare in base al numero di argomenti specificati e ai tipi di dati degli argomenti. È possibile usare l'overload per simulare funzioni con un numero variabile di argomenti, fino al limite consentito dal comando [CREATE FUNCTION](r_CREATE_FUNCTION.md).
## Evitare conflitti con le funzioni Amazon Redshift integrate
Si consiglia di denominare tutti UDFs utilizzando il prefisso`f_`. Amazon Redshift riserva il `f_` prefisso esclusivamente per i nomi UDF UDFs e, anteponendo ai nomi UDF`f_`, ti assicuri che il nome UDF non entri in conflitto con nomi di funzione SQL integrati di Amazon Redshift esistenti o futuri. Ad esempio, assegnando a una nuova funzione definita dall'utente `f_sum`, si evita il conflitto con la funzione SUM di Amazon Redshift. Analogamente, se si assegna il nome `f_fibonacci` a una nuova funzione, è possibile evitare un conflitto se Amazon Redshift aggiungerà una funzione denominata FIBONACCI in una versione futura.
È possibile creare una funzione definita dall'utente con lo stesso nome e la stessa firma di una funzione SQL predefinita di Amazon Redshift esistente senza che avvenga l'overload del nome della funzione se la funzione definita dall'utente e la funzione predefinita si trovano in schemi diversi. Poiché le funzioni predefinite si trovano nello schema del catalogo di sistema pg\$1catalog, puoi creare una funzione definita dall'utente con lo stesso nome in un altro schema, ad esempio uno schema pubblico o definito dall'utente. In alcuni casi, è possibile chiamare una funzione non qualificata esplicitamente con un nome di schema. In tal caso, Amazon Redshift cerca prima lo schema pg\$1catalog per impostazione predefinita. Pertanto, una funzione incorporata viene eseguita prima di una nuova funzione definita dall'utente con lo stesso nome.
È possibile modificare questo comportamento impostando il percorso di ricerca in modo da aggiungere pg\$1catalog alla fine. In tal caso, l'utente ha la precedenza sulle funzioni integrate, ma la pratica UDFs può portare a risultati inaspettati. L'adozione di una strategia di denominazione univoca, ad esempio usando il prefisso riservato `f_`, è un approccio più affidabile. Per ulteriori informazioni, consultare [SET](r_SET.md) e [search\$1path](r_search_path.md).