Amazon Redshift will no longer support the creation of new Python UDFs starting Patch 198. Existing Python UDFs will continue to function until June 30, 2026. For more information, see the [ blog post ](https://amazonaws-china.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
# Associating a datashare from a different Amazon Web Services account in Amazon Redshift
With Amazon Redshift, you can associate datashares shared by other Amazon Web Services accounts, enabling seamless and secure data sharing across organizational boundaries. Datashares are shareable database objects that encapsulate data from one or more Amazon Redshift databases. The following sections demonstrate the process of associating datashares.
------
#### [ Console ]
As a consumer administrator, you can associate one or more datashares that are shared from other accounts to your entire Amazon account or specific namespaces in your account.
1. Sign in to the Amazon Web Services Management Console and open the Amazon Redshift console at [https://console.amazonaws.cn/redshiftv2/](https://console.amazonaws.cn/redshiftv2/).
1. On the navigation menu, choose **Datashares**. The datashare list page appears. Choose **From other accounts**.
1. In the **Datashares from other accounts** section, choose the datashare that you want to associate and choose **Associate**. When the **Associate** datashare page appears, choose one of the following association types:
+ Choose **Entire Amazon account** to associate all existing and future namespaces across different Amazon Regions in your Amazon account with the datashare.
+ If the datashare is published to the Amazon Glue Data Catalog, you can only associate the datashare with the entire Amazon account.
1. From here you can choose **Allowed permissions**. The choices are:
+ **Read-only** – If you choose read only, write permissions like UPDATE or INSERT aren't available on the consumer, even if these permissions were granted and authorized on the producer.
+ **Read and write** – Consumer datashare users will have all of the permissions, both read and write, that were granted and authorized by the producer.
1. Alternatively, choose **Specific Amazon Regions and namespaces** to associate one or more Amazon Regions and specific namespaces with the datashare. Choose **Add Region** to add specific Amazon Regions and namespaces to the datashare. The **Add Amazon Region** page appears.
1. Choose an **Amazon Region**.
1. Do one of the following:
+ Choose **Add all namespaces** to add all existing and future namespaces in this Region to the datashare.
+ Choose **Add specific namespaces** to add one or more specific namespaces in this Region to the datashare.
+ Choose one or more namespaces and choose **Add Amazon Region**.
1. Choose **Associate**.
It's possible for the producer to go back and change settings for an authorization, which can affect association settings on consumers.
If you're associating the datashare with a Lake Formation account, go to the Lake Formation console to create a database, then define permissions over the database. For more information, see [ Setting up permissions for Amazon Redshift datashares](https://docs.amazonaws.cn/lake-formation/latest/dg/setup-ds-perms.html) in the Amazon Lake Formation Developer Guide. Once you create a Amazon Glue database or a federated database, you can use query editor v2 or any preferred SQL client with your consumer cluster to query the data.
After the datashare is associated, the datashares become available.
**Note**
You can also change datashare association at any time. When changing association from specific Amazon Regions and namespaces to the entire Amazon account, Amazon Redshift overwrites the specific Region and namespaces information with Amazon account information. All the Amazon Regions and namespaces in the Amazon Web Services account then have access to the datashare.
------
#### [ API ]
**Note**
The steps in this section are performed after the producer administrator grants specific actions on the shared database objects and, if the datashare is being shared with another account, the producer security administrator authorizes access.
The consumer security administrator determines the following:
+ Whether or not all namespaces in an account, namespaces in specific regions in the account, or specific namespaces have access to the datashare.
+ If namespaces have access to the datashare, whether or not those namespace have write permissions.
The consumer security administrator can associate the datashare with the following command:
```
associate-data-share-consumer
--data-share-arn
--consumer-identifier
[--allow-writes | --no-allow-writes]
```
For more information about the command, see [associate-data-share-consumer](https://docs.amazonaws.cn/cli/latest/reference/redshift/associate-data-share-consumer.html).
The consumer security administrator must explicitly set `allow-writes` to true when associating a datashare with a namespace, to allow use of INSERT and UPDATE commands. If they don't, the users can perform only read operations, such as SELECT, USAGE, or EXECUTE privileges.
You can change the association of a namespace for a datashare by calling `associate-data-share-consumer` again, with a different value. The old association is overwritten by the new association, so if you originally associate and set `allow-writes`, but associate and specify `no-allow-writes`, or simply do not specify a value, the consumer will have their write permissions revoked.
------