View a markdown version of this page

Utiliser l'API de métadonnées du pilote Amazon Redshift pour les applications et les outils - Amazon Redshift

Amazon Redshift ne prendra plus en charge l'utilisation des UDF Python après le 30 juin 2026. Nous allons commencer à l'appliquer par étapes. Pour plus d'informations sur les détails de la fin de vie de Python et des options de migration, consultez le billet de blog publié le 30 juin 2025.

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.

Utiliser l'API de métadonnées du pilote Amazon Redshift pour les applications et les outils

Pour les applications et les outils qui se connectent à Amazon Redshift, tels qu'un outil d'informatique décisionnelle ou un éditeur de requêtes, nous vous recommandons d'utiliser l'API de métadonnées du pilote fournie par les pilotes Amazon Redshift JDBC 2.x, ODBC 2.x ou Python pour découvrir les métadonnées relatives aux objets de votre entrepôt de données, notamment les bases de données, les schémas, les tables, les colonnes et les types de données. Comme alternative, vous pouvez utiliser les SHOW commandes Amazon Redshift.

Utilisez l'API de métadonnées du pilote pour bénéficier des avantages suivants :

  • Specification-compliant. Les pilotes JDBC et ODBC implémentent des interfaces de métadonnées standard (DatabaseMetaDataen JDBC et en ODBC). SQLTables SQLColumns Étant donné que Python DB-API (PEP 249) ne définit pas de spécification d'API de métadonnées, le pilote Python Amazon Redshift suit la DatabaseMetaData spécification JDBC et fournit des méthodes équivalentes telles queget_tables(), et. get_columns() get_schemas() Ces API suivent des spécifications bien définies, de sorte que votre code d'intégration est portable. Au fur et à mesure qu'Amazon Redshift fait évoluer ses tables système internes, il n'est pas nécessaire de modifier votre application.

  • Performance-optimized. L'API des métadonnées du pilote est optimisée pour renvoyer efficacement les métadonnées. AWS continue d'investir dans les performances de l'API des métadonnées des pilotes.

  • Forward-compatible. Amazon Redshift respecte les spécifications des connecteurs JDBC, ODBC et Python. Lorsque vous codez à l'aide de ces API standard, votre application est protégée contre les modifications apportées à la structure du catalogue système sous-jacent.

Exemple : utilisation de JDBC DatabaseMetaData.getTables () pour récupérer les métadonnées d'une table

DatabaseMetaData dbmd = connection.getMetaData(); // getTables(catalog, schemaPattern, tableNamePattern, types) // catalog: "test" — filters to the database named "test" // schemaPattern: "test_pattern" — filters schemas matching this pattern (supports SQL wildcards % and _) // tableNamePattern: null — no filter, returns all table names // types: {"TABLE", "EXTERNAL TABLE"} — only return regular tables and external tables ResultSet rs = dbmd.getTables("test", "test_pattern", null, new String[] {"TABLE", "EXTERNAL TABLE"});

Exemple : utilisation de Python cursor.get_columns () pour récupérer les métadonnées des colonnes

cursor: redshift_connector.Cursor = conn.cursor() # get_columns(catalog, schema_pattern, table_name_pattern, column_name_pattern) # catalog: 'test' — filters to the database named "test" # schema_pattern: 'test_pattern' — filters schemas matching this pattern (supports SQL wildcards % and _) # table_name_pattern: 'testabc' — filters to the table named "testabc" # column_name_pattern: '%' — wildcard, returns all columns in the matching table result: tuple = cursor.get_columns('test', 'test_pattern', 'testabc', '%')

Exemple : utilisation d'ODBC SQLPrimaryKeys () pour récupérer les métadonnées de la clé primaire

// SQLPrimaryKeys(hstmt, catalog, catalog_len, schema, schema_len, table, table_len) // catalog: "test" — filters to the database named "test" // schema: "test_schema" — filters to the schema named "test_schema" // table: "test_table" — retrieves primary key columns for this table // Note: Unlike getTables/getColumns, SQLPrimaryKeys does NOT support wildcard patterns. retcode = SQLPrimaryKeys(hstmt, (SQLCHAR *)"test", SQL_NTS, (SQLCHAR *)"test_schema", SQL_NTS, (SQLCHAR *)"test_table", SQL_NTS); while (SQL_SUCCEEDED(retcode = SQLFetch(hstmt))) { for (i = 1; i <= columns; i++) { retcode = SQLGetData(hstmt, i, SQL_C_CHAR, buf, sizeof(buf), &indicator); } }

Exemple : utilisation d'ODBC SQLtables () pour répertorier les bases de données et les schémas

L'API ODBC ne fournit pas de fonctions distinctes pour répertorier les catalogues ou les schémas. Vous utilisez plutôt des conventions d'appel spéciales SQLTables() pour récupérer ces informations.

Pour répertorier toutes les bases de données (catalogues)

Appelez SQLTables() avec CatalogName réglé àSQL_ALL_CATALOGS. Définissez SchemaName et TableName pour vider les chaînes. Le jeu de résultats renvoie des valeurs valides uniquement dans la TABLE_CAT colonne. Toutes les autres colonnes contiennent des valeurs NULL.

// List all catalogs (databases) available on the data source. retcode = SQLTables(hstmt, (SQLCHAR *)SQL_ALL_CATALOGS, SQL_NTS, // CatalogName = "%" (SQL_ALL_CATALOGS) (SQLCHAR *)"", 0, // SchemaName = "" (empty string) (SQLCHAR *)"", 0, // TableName = "" (empty string) NULL, 0); // TableType = NULL (not filtered)

Pour répertorier tous les schémas

Appelez SQLTables() avec SchemaName réglé àSQL_ALL_SCHEMAS. Définissez CatalogName et TableName pour vider les chaînes.

// List all schemas available on the data source. retcode = SQLTables(hstmt, (SQLCHAR *)"", 0, // CatalogName = "" (empty string) (SQLCHAR *)SQL_ALL_SCHEMAS, SQL_NTS, // SchemaName = "%" (SQL_ALL_SCHEMAS) (SQLCHAR *)"", 0, // TableName = "" (empty string) NULL, 0); // TableType = NULL (not filtered)
Note

La spécification ODBC définit uniquement TABLE_SCHEM comme valide pour l'énumération des schémas. Amazon Redshift est également renseigné TABLE_CAT car il prend en charge la découverte de métadonnées entre bases de données et chaque schéma est limité à une base de données spécifique.