Bundle 2021_10¶
Unter diesem Thema werden die folgenden in diesem Monat vorgenommenen Verhaltensänderungen (falls vorhanden) beschrieben:
Features, die veraltet sind.
Gebündelte Änderungen, die aktiviert wurden.
Andere, nicht gebündelte Änderungen, die implementiert wurden.
Wenn Sie Fragen zu diesen Änderungen haben, wenden Sie sich an den Snowflake-Support.
Weitere Einzelheiten zu den in diesem Monat eingeführten neuen Features, Erweiterungen und Korrekturen finden Sie unter Februar 2022.
Wichtig
Sofern nicht anders angegeben, sind diese Änderungen in Bundle 2021_10 enthalten, das standardmäßig mit Release 6.2 aktiviert wurde.
Unter diesem Thema:
Sicherheitsänderungen¶
Befehl DESCRIBE USER: Neue Spalten RSA_PUBLIC_KEY und RSA_PUBLIC_KEY_2 in Ausgabe¶
Die Ausgabe des Befehls DESCRIBE USER enthält zwei neue Spalten:
RSA_PUBLIC_KEY
RSA_PUBLIC_KEY_2
Diese beiden Spalten erleichtern das Abrufen der öffentlichen Schlüssel, die derzeit für den Benutzer eingestellt sind.
SQL-Änderungen – Allgemein¶
Einschränkungen: Änderungen an der RELY-Einschränkungseigenschaft und zugehörigen Ansichten¶
Das Verhalten der RELY-Einschränkungseigenschaft und von zwei Ansichten für Einschränkungen (TABLE_CONSTRAINTS-Ansicht in ACCOUNT_USAGE und TABLE_CONSTRAINTS-Ansicht in INFORMATION_SCHEMA) hat sich wie folgt geändert:
- Bisher
Wenn Sie eine neue Einschränkung erstellt haben:
RELY war der Standard.
Sie konnten dies nicht überschreiben, indem Sie im Befehl NORELY angeben. Wenn Sie NORELY im Befehl angegeben haben, wurde NORELY ignoriert oder es wurde ein Fehler ausgegeben.
Bei bestehenden Einschränkungen konnten Sie die RELY-Einschränkungseigenschaft nicht ändern.
Die folgenden Ansichten lieferten keine Informationen über die RELY-Einschränkungseigenschaft:
TABLE_CONSTRAINTS in ACCOUNT_USAGE
TABLE_CONSTRAINTS in INFORMATION_SCHEMA
- Jetzt
Wenn Sie eine neue Einschränkung erstellen:
NORELY ist der Standard.
Sie können dies nun überschreiben, indem Sie im Befehl RELY angeben.
Alle vorhandenen Einschränkungen haben die Eigenschaft NORELY (unabhängig davon, ob die Einschränkung derzeit die Eigenschaft RELY oder NORELY hat). Sie können nun die Einschränkungseigenschaft von NORELY auf RELY ändern.
Die folgenden Ansichten enthalten nun eine RELY-Spalte, die angibt, ob die RELY-Einschränkungseigenschaft gesetzt ist oder nicht:
TABLE_CONSTRAINTS in INFORMATION_SCHEMA (Aktualisierung: Die Spalte RELY wurde im August 2022 hinzugefügt.)
Die Spalte RELY wird in einem der nächsten Releases zu TABLE_CONSTRAINTS in ACCOUNT_USAGE hinzugefügt.
Diese Änderung wurde vorgenommen, um zukünftige Verbesserungen bei der Abfrageoptimierung zu unterstützen. Diese Verbesserungen werden die für die Tabelle definierten Einschränkungen nutzen.
Mit der neuen Standardeinstellung NORELY geht die Abfrageoptimierung nicht davon aus, dass die Daten in einer Tabelle den Einschränkungen entsprechen. Wenn Sie sichergestellt haben, dass die Daten in der Tabelle den Einschränkungen entsprechen, können Sie diesen Wert in RELY ändern (d. h. um anzuzeigen, dass die Abfrageoptimierung erwarten kann, dass die Daten in der Tabelle den Einschränkungen entsprechen).
Materialisierte Ansichten: Änderung der Art und Weise, wie Ansichten beim Klonen von Datenbanken erstellt werden¶
Die Art und Weise, in der materialisierte Ansichten beim Klonen von Datenbanken erstellt werden, hat sich wie folgt geändert:
- Bisher
Wenn Sie eine Datenbank geklont haben, wurden alle materialisierten Ansichten in der geklonten Datenbank mit vollqualifizierten Namen erstellt, auch wenn Sie den vollqualifizierten Namen beim Erstellen der Ansicht in der Originaldatenbank nicht angegeben haben.
Angenommen, Sie haben in der Datenbank
db1
eine materialisierte Ansicht mit dem nicht qualifizierten Namenmv
erstellt:use database db1; create materialized view mv as ...;
Und Sie klonen dann die Datenbank
db1
:create database db1_clone clone db1;
Die Anweisung CREATE MATERIALIZED VIEW, mit der die Ansicht in der geklonten Datenbank erstellt wurde, verwendete den vollqualifizierten Namen der Ansicht.
Sie können diese Anweisung anzeigen, indem Sie den Befehl SHOW MATERIALIZED VIEWS ausführen:
use database db1_clone; show materialized views;
Die Spalte „text“ enthält den Text des Befehls, mit dem diese materialisierte Ansicht erstellt wurde:
| text +------ ... | create or replace materialized view DB1_CLONE.PUBLIC.MV as ...
Wie in diesem Beispiel gezeigt, verwendet der Befehl den vollqualifizierten Namen der materialisierten Ansicht (DB1_CLONE.PUBLIC.MV
).
- Jetzt
Die CREATE MATERIALIZED VIEW-Anweisung in der geklonten Datenbank enthält nicht den Namen der geklonten Datenbank und des Schemas, es sei denn, diese Namen wurden in der ursprünglichen CREATE MATERIALIZED VIEW-Anweisung angegeben.
Angenommen, Sie erstellen in der Datenbank
db1
eine materialisierte Ansicht mit dem nicht qualifizierten Namenmv
:use database db1; create materialized view mv as ...;
Und Sie klonen dann die Datenbank
db1
:create database db1_clone clone db1;
Wenn Sie nun folgenden Befehl ausführen:
use database db1_clone; show materialized views; -- OR -- use database db1_clone; show views;
Die CREATE MATERIALIZED VIEW-Anweisung in der Spalte „text“ verwendet den nicht qualifizierten Namen für die Ansicht, da in der ursprünglichen CREATE MATERIALIZED VIEW-Anweisung der nicht qualifizierte Name verwendet wurde:
| text +------ ... | create or replace materialized view mv as ...
Diese Änderung wurde vorgenommen, um mögliche Probleme beim Umbenennen einer geklonten Datenbank zu vermeiden. Wenn Sie eine geklonte Datenbank umbenennen, wird der ursprüngliche Name der geklonten Datenbank in der materialisierten Ansicht nicht aktualisiert.
Angenommen, Sie benennen die geklonte Datenbank db1_clone
in db2
um:
alter database db1_clone rename to db2;
Und Sie führen nun den folgenden Befehl aus:
use database db2;
show materialized views;
Der Befehl in der Spalte „text“ verwendet den ursprünglichen Namen der geklonten Datenbank (db1_clone
), nicht den neuen Namen der geklonten Datenbank (db2
):
| text
+------ ...
| create or replace materialized view DB1_CLONE.PUBLIC.MV as ...
Infolgedessen führt die Abfrage der materialisierten Ansicht zu einem Fehler:
select * from mv;
SQL compilation error: Failure during expansion of view 'MV': Cannot perform SELECT.
Diese Verhaltensänderung verhindert, dass dieser Fehler auftritt.
SQL-Änderungen – Befehle und Funktionen¶
Befehl SHOW ORGANIZATIONACCOUNTS: Neue Spalten in Ausgabe¶
Zum besseren Verständnis der Zuordnungen von Konten zu Abrechnungseinheiten in einer Organisation wurden die folgenden Spalten zur Ausgabe des Befehls SHOW ORGANIZATION ACCOUNTS hinzugefügt:
Spaltenname |
Datentyp |
Beschreibung |
---|---|---|
CONSUMPTION_BILLING_ENTITY_NAME |
TEXT |
Der Name der Verbrauchsabrechnungseinheit. |
MARKETPLACE_CONSUMER_BILLING_ENTITY_NAME |
TEXT |
Der Name der Abrechnungseinheit des Marketplace-Verbrauchers. |
MARKETPLACE_PROVIDER_BILLING_ENTITY_NAME |
TEXT |
Der Name der Abrechnungseinheit des Marketplace-Anbieters. |
Funktion GET_DDL: Änderungen bei Ansichten¶
Die Funktion GET_DDL gibt eine DDL-Anweisung zurück, mit der das angegebene Objekt neu erstellt werden kann, wobei die Ausgabe der Abfrage je nach dem im Funktionsargument angegebenen Objekt variiert. Das Verhalten der GET_DDL-Funktion bei Ansichten hat sich wie folgt geändert:
- Bisher
Snowflake gab die genaue SQL-Anweisung zum Neuerstellen der Ansicht zurück. Wenn die Ansicht eine sichere Ansicht war, gab Snowflake die DDL-Anweisung zum Erstellen der Ansicht sowie eine ALTER-Anweisung zurück, um die Eigenschaft SECURE für die Ansicht festzulegen.
- Jetzt
Snowflake hat das Abfrageergebnis für Ansichten wie folgt aktualisiert:
Das Abfrageergebnis gibt SQL-Text in Kleinbuchstaben für
create or replace view
zurück, auch wenn in der ursprünglichen SQL-Anweisung, die zum Erstellen der Ansicht verwendet wurde, Großschreibung oder gemischte Klein-/Großschreibung verwendet wurde.Die OR REPLACE-Klausel ist immer in der CREATE VIEW-Anweisung enthalten.
SQL-Kommentare vor dem Ansichtstext (AS) werden entfernt.
Die Spaltenliste wird immer generiert. Wenn auf einer Spalte eine Maskierungsrichtlinie festgelegt ist, gibt das Ergebnis die Maskierungsrichtlinie für die Spalte an.
Wenn die Ansicht eine Maskierungsrichtlinie für eine oder mehrere ihrer Spalten oder eine Zeilenzugriffsrichtlinie hat und die Rolle, die die GET_DDL-Abfrage ausführt, nicht über die globale Berechtigung APPLY MASKING POLICY oder APPLY ROW ACCESS POLICY verfügt, wird der Richtlinienname durch
#unknown_policy
ersetzt (siehe Hinweis unten).Wenn die Ansicht sicher ist, enthält das Abfrageergebnis die SECURE-Eigenschaft in der CREATE-Anweisung. Eine zusätzliche ALTER-Anweisung zur Festlegung der SECURE-Eigenschaft ist nicht mehr im Abfrageergebnis enthalten.
COPY GRANTS ist nicht enthalten, auch wenn es in der ursprünglichen CREATE VIEW-Anweisung angegeben wurde.
Es ist sichergestellt, dass die CREATE VIEW-Anweisung immer mit einem Semikolon endet.
Bemerkung
Bei einer Ansicht, die eine Maskierungsrichtlinie, eine Zeilenzugriffsrichtlinie oder beides enthält, führt das ausstehende Abfrageergebnis mit dem Text
#unknown_policy
dazu, dass die CREATE VIEW-Anweisung fehlschlägt, wenn dieser Text nicht vor der Neuerstellung der Ansicht entfernt wird. Dieses Verhalten wird erwartet. Die Verwendung dieses Textes soll darauf hinweisen, dass die Spalte oder die Ansicht durch eine Richtlinie geschützt ist.Wenn das GET_DDL-Abfrageergebnis den
#unknown_policy
-Text enthält, wenden Sie sich vor der Neuerstellung der Ansicht an Ihren internen Governance-Administrator, um festzustellen, welche Richtlinien für die Spalten oder die Ansicht erforderlich sind. Bearbeiten Sie das GET_DDL-Abfrageergebnis entsprechend, und erstellen Sie dann die Ansicht neu.
INFER_SCHEMA-Funktion: Änderung bei NULL-Spalten¶
Die Funktion INFER_SCHEMA erkennt die Spaltendefinitionen in einer Menge von Staging-Datendateien, die semistrukturierte Daten enthalten, und ruft die Metadaten in einem Format ab, das für die Erstellung von Snowflake-Objekten geeignet ist.
Die Bedingung, die bestimmt, ob die Funktion die NULL- oder NOT NULL-Einschränkung für eine Spalte zurückgibt, wurde wie folgt geändert:
- Bisher
Die Funktion INFER_SCHEMA gibt die NULL-Zulässigkeitseinschränkung für eine Spalte zurück, wie sie in den Metadaten der Dateien, die die Spalte enthalten, angegeben ist. Wenn die Eingabe für die Funktion eine einzelne Datei war, war die für die Spalten zurückgegebene NULL-Zulässigkeitseinschränkung immer korrekt. Wenn jedoch eine Spalte in den Metadaten als erforderlich identifiziert wurde, aber nicht in allen Eingabedateien enthalten war, lieferte die Funktion dennoch eine NOT NULL-Einschränkung für die Spalte. Diese Logik kann zu Fehlern führen, wenn alle Dateien in eine Tabelle geladen werden, die mit der Ausgabe der INFER_SCHEMA-Funktion erstellt wurde.
Beim Erstellen einer Tabelle mit den Spaltendefinitionen, die aus einer Menge von Staging-Datendateien abgeleitet wurden (unter Verwendung der CREATE TABLE … USING TEMPLATE-Syntax), wurden alle Spalten in der Tabelle als nullwertfähig definiert.
- Jetzt
Die Funktion INFER_SCHEMA gibt eine Spalte als nullwertfähig zurück, wenn die Spalte in den Eingabedateien fehlt oder als optional angegeben ist. Die Funktion gibt eine Spalte nur dann als nicht nullwertfähig zurück, wenn die Spalte in allen Eingabedateien als erforderlich gekennzeichnet ist.
Die Funktion GENERATE_COLUMN_DESCRIPTION und die Syntax des CREATE TABLE … USING TEMPLATE-Befehls folgen demselben NULL-Zulässigkeitsverhalten wie die Funktion INFER_SCHEMA.
SQL-Änderungen – Nutzungsansichten & Information Schema¶
Ansicht ACCESS_HISTORY: Unterstützung von Schreiboperationen¶
Das Verhalten von ACCESS_HISTORY-Ansicht im ACCOUNT_USAGE-Schema hat sich wie folgt geändert:
- Bisher
Die Ansicht ACCESS_HISTORY unterstützte nur SQL-Leseoperationen.
- Jetzt
Die Ansicht ACCESS_HISTORY unterstützt SQL-Lese-/Schreiboperationen wie folgt:
Es wurden zusätzliche Zeilen in die Abfrageausgabe der Ansicht hinzugefügt, um anzuzeigen, dass Schreiboperationen stattgefunden haben.
Die neue Spalte OBJECTS_MODIFIED vom Datentyp ARRAY gibt Objekte an, die im Schreibteil einer SQL-Abfrage geändert wurden.
Wenn auf einen Stagingbereich zugegriffen wurde, gibt das Feld
objectDomain
den Wert STAGE an.Wenn im Leseteil der Abfrage auf einen Stagingbereich zugegriffen wurde, wurden die Spalten DIRECT_OBJECTS_ACCESSED und BASE_OBJECTS_ACCESSEDn wie folgt aktualisiert:
In dem neuen JSON-Feld
stageKind
wird der Stagingbereich angegeben.In den Feldern
objectName
undobjectId
werden die entsprechenden Werte für den Benutzer, die Tabelle und den benannten Stagingbereich angegeben.
Weitere Informationen zu unterstützten und nicht unterstützten Schreiboperationen finden Sie in den Hinweisen unten.
Beachten Sie Folgendes:
Die Spalte OBJECTS_MODIFIED gibt ein Array im folgenden Format zurück:
{ "columns": [ { "columnName": <string>, "columnId": <number> }, { "columnName": <string>, "columnId": <number> } ... ], "objectId": <number>, "objectName": <string>, "objectDomain": TABLE | STAGE, "location": <string>, "stageKind": Table | User | Internal Named | External Named }
Wenn im Schreibteil der Abfrage auf einen Stagingbereich zugegriffen wurde:
Der Wert von
objectId
lautet wie folgt:NAME – Bezeichner für einen Benutzer (Benutzer-Stagingbereich).
TABLE_ID – Nummer für eine Tabelle (Tabellen-Stagingbereich).
STAGE_ID – Nummer für einen Stagingbereich (Benannter Stagingbereich).
Der Wert von
objectName
lautet wie folgt:Benutzer-Stagingbereich: Der Wert ist der Wert von
username
.Tabellen-Stagingbereich: Der Wert ist der Wert von
table_name
.Benannter Stagingbereich: Der Wert ist der Wert von
stage_name
.
Wenn im Schreibteil der Abfrage auf einen Stagingbereich zugegriffen wurde, enthalten die Spalten BASE_OBJECTS_ACCESSED und DIRECT_OBJECTS_ACCESSED die folgenden JSON-Felder:
{ "objectDomain": STAGE "objectName": <string>, "objectId": <number>, "stageKind": <string> }
Die möglichen Werte für die Feldnamen in diesen beiden Spalten sind die gleichen wie in der Spalte OBJECTS_MODIFIED.
Snowflake unterstützt die folgenden Schreiboperationen in der ACCESS_HISTORY-Ansicht:
GET <interner_Stagingbereich>
PUT <interner_Stagingbereich>
DELETE
INSERT
INSERT INTO … FROM SELECT *
INSERT INTO TABLE … VALUES ()
MERGE INTO … FROM SELECT *
UPDATE
UPDATE TABLE … FROM SELECT * FROM …
UPDATE TABLE … WHERE …
Anweisungen zum Laden von Daten:
COPY INTO TABLE FROM internalStage
COPY INTO TABLE FROM externalStage
COPY INTO TABLE FROM externalLocation
Anweisungen zum Entladen von Daten:
COPY INTO internalStage FROM TABLE
COPY INTO externalStage FROM TABLE
COPY INTO externalLocation FROM TABLE
CREATE:
CREATE DATABASE … CLONE
CREATE SCHEMA … CLONE
CREATE TABLE … CLONE
CREATE TABLE … AS SELECT
Snowflake unterstützt die folgenden Schreiboperationen in der ACCESS_HISTORY-Ansicht nicht:
Operationen zum Befüllen von Ansichten, materialisierten Ansichten und Streams
Verschieben von Daten für Replikation
COPY_HISTORY: Konsistent Schreibung in STATUS-Spalte der Ausgabe¶
Der Status einer Datenladeoperation wird in der Ausgabe der Information Schema-Tabellenfunktion COPY_HISTORY und in der COPY_HISTORY-Ansicht von ACCOUNT_USAGE jeweils in der Spalte STATUS angegeben. Die in der Spalte STATUS zurückgegebenen Werte haben sich wie folgt geändert:
- Bisher
Beim Massenladen von Daten (COPY INTO <Tabelle>-Anweisungen) wurden die Statuswerte mit dem ersten Buchstaben des ersten Wortes in Großbuchstaben und den restlichen Wörtern in Kleinbuchstaben zurückgegeben:
Loaded
,Load failed
usw.Beim Laden von Snowpipe-Daten wurden die Statuswerte in Großbuchstaben zurückgegeben:
LOADED
,LOAD FAILED
usw.- Jetzt
Sowohl beim Massenladen von Daten als auch beim Laden von Snowpipe-Daten werden die Statuswerte mit dem ersten Buchstaben des ersten Wortes in Großbuchstaben und den restlichen Wörtern in Kleinbuchstaben zurückgegeben.
Durch diese Änderung werden die Werte in den STATUS-Spalten konsistent und in Übereinstimmung mit der Produktdokumentation angegeben.
Änderungen an der Erweiterbarkeit¶
Java-UDFs: Änderungen an Aufnahmekriterien für Scala-JAR-Dateien¶
Das Verhalten von Java-UDFs hat sich wie folgt geändert:
- Bisher
Beo Java-UDFs wurden Scala-JAR-Dateien in den JVM-Klassenpfad aufgenommen.
- Jetzt
Bei Java-UDFs werden Scala-Bibliotheken nicht mehr in den Klassenpfad aufgenommen. Wenn Sie Java-UDF-Code verwenden, der von Scala-Bibliotheken abhängt, müssen Sie beim Erstellen neuer UDFs oder beim Ersetzen bestehender UDFs die entsprechenden Scala-JAR-Dateien zur Importliste hinzufügen. Beispiel:
create or replace function add(x integer, y integer) returns integer language java imports = ('@stage/scala-library-2.12.jar') handler='TestAddFunc.add'
UDFs, die mit der Snowpark-Scala-Bibliothek erstellt wurden, sind davon nicht betroffen.
Änderungen beim Laden von Daten¶
Befehl COPY INTO <Tabelle>: Kopieroption MATCH_BY_COLUMN_NAME liefert beim Laden von CSV-Daten einen Fehler¶
Mit der Kopieroption MATCH_BY_COLUMN_NAME können semistrukturierte Daten in separate Spalten einer Zieltabelle geladen werden, die aber mit den entsprechenden Spalten in den Quelldaten übereinstimmen müssen. Die Kopieroption unterstützt nicht das Laden von Daten aus Dateien mit durch Trennzeichen getrennten Werten (CSV).
Das Verhalten beim Versuch, CSV-formatierte Daten zu laden, wenn die Kopieroption MATCH_BY_COLUMN_NAME entweder auf CASE_SENSITIVE oder CASE_INSENSITIVE gesetzt ist, hat sich wie folgt geändert:
- Bisher
Die Anweisung COPY INTO <Tabelle> gab keinen Fehler zurück, wenn sie mit Dateien im CSV-Format verwendet wurde, aber die MATCH_BY_COLUMN_NAME-Einstellung hatte keinen Einfluss auf das Laden der Daten und wurde ignoriert.
- Jetzt
Die Anweisung COPY INTO <Tabelle> gibt einen Benutzerfehler zurück, da die Option keine CSV-Dateien unterstützt.
Befehl COPY INTO <Speicherort>: Explizites Umwandeln von Spalten wird beim Entladen in Parquet-Daten ignoriert¶
Beim Entladen numerischer Tabellendaten in Parquet-Dateien können Sie durch Aufruf der CAST-Funktion in der COPY INTO <Speicherort>-Anweisung die Snowflake-Datentypen auswählen, die Parquet-Datentypen zugeordnet werden sollen.
Das Verhalten beim expliziten Umwandeln von numerischen Spaltendaten in Parquet-Dateien hat sich wie folgt geändert:
- Bisher
Wenn mindestens eine numerische Spalte explizit in einen Datentyp umgewandelt wurde, der keinem Parquet-Datentyp zugeordnet war, dann ignorierte die Datenentladeoperation sämtliche expliziten Umwandlungen, auch wenn diese Parquet-Datentypen zugeordnet waren. Spalten mit Festkommazahlen wurden als DECIMAL-Spalten entladen, während Spalten mit Gleitkommazahlen als DOUBLE-Spalten entladen wurden.
- Jetzt
Datenentladeoperationen berücksichtigen alle expliziten Umwandlungen von numerischen Spaltendaten, unabhängig davon, ob die Snowflake-Zieldatentypen bestimmten Parquet-Datentypen zugeordnet sind.
Aktualisierungen bei Datenfreigaben (Data Sharing)¶
Verwaltete Konten: Änderungen zur Unterstützung eines neuen Kontonamensformats¶
Snowflake führt eine neue URL ein, die auf einem aktualisierten Namen für verwaltete Konten basiert, den Kunden auswählen und ändern können. Die URL hat das folgende Format:
<Organisationsname>-<Name_des_verwalteten_Kontos>.snowflakecomputing.com
Für den neuen Name von verwalteten Konten gelten zwei neue Benennungsregeln:
Der Unterstrich (_) ist das einzige gültige Trennzeichen im Namen.
Der Name muss innerhalb der Organisation, zu der das verwaltete Konto gehört, eindeutig sein.
Die meisten bestehenden Namen für verwaltete Konten entsprechen bereits den neuen Benennungsregeln, sodass die Namen unverändert bleiben. Namen von verwalteten Konten, die diesen Regeln nicht entsprachen, werden automatisch wie folgt aktualisiert:
Wenn der Name des verwalteten Kontos Trennzeichen enthält, die keine Unterstriche sind, werden diese in Unterstriche umgewandelt. Wenn der Name des verwalteten Kontos beispielsweise
managed account-1
ist, lautet der neue Name des verwalteten Kontosmanaged_account_1
.Wenn der Name des verwalteten Kontos für die Organisation nicht eindeutig ist, wird der Name des Konto-Locators an den Namen des verwalteten Kontos angehängt. Wenn der Name des verwalteten Kontos beispielsweise
managed
mit dem LocatorRE47190
ist, lautet der neue Name des verwalteten Kontosmanaged_RE47190
.
Der aktualisierte Name von verwalteten Konten wird in allen Befehlen für verwaltete Konten verwendet:
CREATE MANAGED ACCOUNT setzt die neuen Benennungsregeln durch.
SHOW MANAGED ACCOUNTS zeigt den aktualisierten Namen des verwalteten Kontos in der Spalte „Name“ an.
DROP MANAGED ACCOUNT verwendet den aktualisierten Namen des verwalteten Kontos als Parameter.
Befehl SHOW MANAGED ACCOUNTS: Neues Kontonamensfeld in der Ausgabe¶
Mit diesem Release ändert sich die Ausgabe des Befehls SHOW MANAGED ACCOUNTS wie folgt:
- Bisher
In der URL-Spalte wurde die URL des Konto-Locators im folgenden Format angezeigt:
<Konto-Locator>.snowflakecomputing.com
- Jetzt
Die URL-Spalte zeigt die URL des Kontonamens im neuen URL-Format an, der für das Feature „Organisationen“ eingeführt wurde. Die neue URL hat das folgende Format:
<Organisationsname>-<Name_des_verwalteten_Kontos>.snowflakecomputing.com
Außerdem enthält die Ausgabe eine neue Spalte, account_locator_url
, um die URL des Konto-Locators anzuzeigen.
Bemerkung
Abhängig von der Region und der Cloudplattform, auf der Ihr Konto gehostet wird, kann die URL Konto-Locators zusätzliche Segmente wie folgt aufweisen:
<Konto-Locator>.<Regionscode>.<Cloud>.snowflakecomputing.com
Die bestehende Konto-Locator-URL wird neben der neuen URL weiterhin funktionieren wie bisher.