Rozpoznawanie nazw

Dotyczy:zaznacz pole wyboru oznaczone jako tak Databricks SQL zaznacz pole wyboru oznaczone jako tak Databricks Runtime

Rozpoznawanie nazw to proces, za pomocą którego identyfikatory są rozpoznawane dla określonych kolumn, pól, parametrów lub odwołań do tabeli.

Rozdzielczość kolumn, pola, parametru i zmiennej

Identyfikatory w wyrażeniach mogą być odwołaniami do dowolnego z następujących elementów:

Rozpoznawanie nazw stosuje następujące zasady:

  • Najbliższe dopasowanie odniesienia wygrywa, i
  • Kolumny i parametry są preferowane nad polami i kluczami.

Szczegółowo rozpoznawanie identyfikatorów do określonego odwołania jest zgodne z następującymi regułami w następującej kolejności:

  1. Odwołania lokalne

    1. odwołania do kolumny

      Dopasuj identyfikator, który może być kwalifikowany, do nazwy kolumny w odwołaniu do tabeli FROM clause.

      Jeśli istnieje więcej niż jedno dopasowanie, zgłoś błąd AMBIGUOUS_COLUMN_OR_FIELD .

    2. Dokumentacja funkcji bez parametrów

      Jeśli identyfikator jest niekwalifikowany i pasuje do current_user, current_datelub current_timestamp: Rozwiąż go jako jedną z tych funkcji.

    3. Domyślna Specyfikacja Kolumny

      Jeśli identyfikator jest niekwalifikowany, pasuje do default i tworzy całe wyrażenie w kontekście UPDATE SET, INSERT VALUESlub MERGE WHEN [NOT] MATCHED: Rozstrzygnij jako wartość odpowiadającą DEFAULT w tabeli docelowej INSERT, UPDATE lub MERGE.

    4. Odwołanie do pola struktury lub klucza mapy

      Jeśli identyfikator jest kwalifikowany, spróbuj dopasować go do pola lub klucza mapy zgodnie z następującymi krokami:

      Odp. Usuń ostatni identyfikator i traktuj go jako pole lub klucz. B. Dopasuj resztę do kolumny w odwołaniu do tabeliFROM clause.

      Jeśli istnieje więcej niż jedno dopasowanie, zgłoś błąd AMBIGUOUS_COLUMN_OR_FIELD .

      Jeśli istnieje dopasowanie, a kolumna to:

      • STRUCT: Dopasuj pole.

        Jeśli nie można dopasować pola, zgłoś błąd FIELD_NOT_FOUND .

        Jeśli istnieje więcej niż jedno pole, zgłoś błąd AMBIGUOUS_COLUMN_OR_FIELD .

      • MAP: zgłoś błąd, jeśli klucz jest kwalifikowany.

        Błąd środowiska uruchomieniowego może wystąpić, jeśli klucz nie jest rzeczywiście obecny na mapie.

      • Dowolny inny typ: zgłoś błąd. C. Powtórz poprzedni krok, aby usunąć identyfikator końcowy jako pole. Zastosuj reguły (A) i (B), gdy pozostaje identyfikator do zinterpretowania jako kolumna.

  2. aliasowanie bocznej kolumny

    Dotyczy:zaznacz pole wyboru oznaczone jako tak Databricks SQL zaznacz pole wyboru oznaczone jako tak Databricks Runtime 12.2 LTS i nowsze

    Jeśli wyrażenie znajduje się na liście SELECT, dopasuj wiodący identyfikator do poprzedniego aliasu kolumny na tej liście SELECT.

    Jeśli istnieje więcej niż jedno takie dopasowanie, wygeneruj błąd AMBIGUOUS_LATERAL_COLUMN_ALIAS.

    Dopasuj każdy pozostały identyfikator jako pole lub klucz mapy i zgłoś błąd FIELD_NOT_FOUND lub AMBIGUOUS_COLUMN_OR_FIELD, jeśli nie można ich dopasować.

  3. Korelacja

    • BOCZNY

      Jeśli zapytanie jest poprzedzone słowem kluczowym LATERAL, zastosuj reguły 1.a i 1.d, biorąc pod uwagę odwołania do tabeli w FROM zawierające zapytanie i poprzedzające LATERAL.

    • Normalna

      Jeśli zapytanie jest podzapytaniem skalarnym, INlub EXISTS podzapytaniem zastosuj reguły 1.a, 1.d i 2, biorąc pod uwagę odwołania do tabeli w klauzuli zawierającej FROM zapytanie.

  4. Korelacja zagnieżdżona

    Dotyczy do:zaznaczyło tak, Databricks SQL oznaczono tak, Databricks Runtime 20.0 i nowsze

    Ponownie zastosuj regułę 3, iterując poziomy zagnieżdżenia zapytania, aby identyfikator mógł rozwiązywać się do powiązanej referencji w dowolnym zapytaniu zamykającym, a nie tylko w tym bezpośrednio zamykającym.

  5. Pętla FOR

    Jeśli instrukcja jest zawarta w pętli FOR:

    Odp. Dopasuj identyfikator do kolumny w zapytaniu instrukcji pętli FOR. Jeśli identyfikator jest kwalifikowany, kwalifikator musi być zgodny z nazwą zmiennej pętli FOR, jeśli jest zdefiniowana. B. Jeśli identyfikator jest kwalifikowany, dopasuj do pola lub klucza mapy parametru zgodnie z regułą 1.c

  6. instrukcja złożona

    Jeśli instrukcja jest zawarta w instrukcji złożonej:

    Odp. Dopasuj identyfikator do zmiennej zadeklarowanej w tej instrukcji złożonej. Jeśli identyfikator jest kwalifikowany, kwalifikator musi odpowiadać etykiecie instrukcji kompleksowej, jeśli została zdefiniowana. B. Jeśli identyfikator jest kwalifikowany, dopasuj do pola lub klucza mapy zmiennej zgodnie z regułą 1.c

  7. instrukcja złożona zagnieżdżona lub pętla FOR

    Ponownie zastosuj reguły 5 i 6, iterując przez poziomy zagnieżdżania instrukcji złożonej.

  8. parametry procedury

    Jeśli wyrażenie jest częścią instrukcji CREATE FUNCTION lub CREATE PROCEDURE:

    1. Dopasuj identyfikator do nazwy parametru . Jeśli identyfikator jest kwalifikowany, kwalifikator musi być zgodny z nazwą procedury.
    2. Jeśli identyfikator jest kwalifikowany, dopasuj do pola lub klucza mapy parametru zgodnie z regułą 1.c

  9. Zmienne Sesji

    1. Dopasuj identyfikator do nazwy zmiennej . Jeśli identyfikator jest kwalifikowany, kwalifikator musi być session lub system.session. W Databricks SQL i Databricks Runtime 19 i wyższych niezakwalifikowany identyfikator pasuje do zmiennej sesyjnej tylko wtedy, gdy system.session znajduje się na PATH.
    2. Jeśli identyfikator jest kwalifikowany, dopasuj do pola lub klucza mapy zmiennej zgodnie z regułą 1.c

Rozpoznawanie nazw w systemach HAVING, ORDER BYi QUALIFY

Klauzule HAVING, ORDER BYi QUALIFY mogą odwoływać się do nazw z SELECT listy, a także kolumn z tabel bazowych. Gdy nazwa w jednej z tych klauzul pasuje zarówno do aliasu kolumny na SELECT liście, jak i kolumny tabeli, klauzule rozwiązują niejednoznaczność inaczej:

  • ORDER BY preferuje SELECT alias listy w kolumnie tabeli.
  • HAVING preferuje kolumnę tabeli na aliasie SELECT listy.
  • QUALIFY preferuje kolumnę tabeli na aliasie SELECT listy (taki sam jak HAVING).

Przykłady

> CREATE OR REPLACE TEMPORARY VIEW t(a, b) AS VALUES (1, 10), (2, 20), (3, 30);

-- ORDER BY prefers the alias over the column.
-- 'a' in ORDER BY refers to the alias (-a), not column 'a',
-- so the row with the largest column 'a' comes first.
> SELECT -a AS a FROM t ORDER BY a LIMIT 1;
  -3

-- HAVING prefers the column over the alias.
-- 'a' in HAVING refers to column 'a', not the alias sum(b).
> SELECT sum(b) AS a FROM t GROUP BY a HAVING a > 1;
  20
  30

-- QUALIFY prefers the column over the alias (same as HAVING).
-- 'a' in QUALIFY refers to column 'a', not the alias -row_number().
> SELECT -row_number() OVER (ORDER BY b) AS a FROM t QUALIFY a > 1;
  -2
  -3

Wyodrębnianie pól i priorytet rozpoznawania nazw

Jeśli nazwa kwalifikowana, taka jak a.b używana w HAVING systemie lub ORDER BY, powyższe reguły priorytetu nadal mają zastosowanie, ale z dodatkową kwestią: preferowany kandydat musi obsługiwać wyodrębnianie pól struktury lub klucza mapy. Jeśli tak nie jest, zamiast tego zostanie użyty inny kandydat.

Jeśli na przykład alias a jest rozpoznawany jako zwykłyINT, ale kolumna a tabeli jest polem STRUCT z polem x, wybiera ORDER BY kolumnę, STRUCT ponieważ nie można wyodrębnić pola z aliasuINT. Z drugiej strony, jeśli kolumna tabeli jest zwykła INT , a alias to STRUCT, HAVING wraca do aliasu wyodrębniania pól.

Przykłady

-- ORDER BY fallback: the table column is a STRUCT, the alias is an INT.
-- ORDER BY normally prefers the alias, but the alias (INT) cannot have
-- field 'x' extracted, so the struct column wins.
> CREATE OR REPLACE TEMPORARY VIEW s1(a) AS VALUES (named_struct('x', 1)), (named_struct('x', 2));

> SELECT -a.x AS a FROM s1 ORDER BY a.x LIMIT 1;
  -1

-- HAVING fallback: the table column is an INT, the alias is a STRUCT.
-- HAVING normally prefers the table column, but the column (INT) cannot have
-- field 'x' extracted, so the alias wins.
> CREATE OR REPLACE TEMPORARY VIEW s2(a) AS VALUES (1), (2);

> SELECT named_struct('x', 2) AS a FROM s2 GROUP BY a HAVING a.x > 1;
  {"x":2}
  {"x":2}

-- Map key extraction follows the same rules.
-- ORDER BY fallback: alias (INT) cannot have key extracted, map column wins.
> CREATE OR REPLACE TEMPORARY VIEW s3(a) AS VALUES (map('key', 100)), (map('key', 200));

> SELECT -a['key'] AS a FROM s3 ORDER BY a['key'] LIMIT 1;
  -100

-- HAVING fallback: column (INT) cannot have key extracted, map alias wins.
> CREATE OR REPLACE TEMPORARY VIEW s4(a) AS VALUES (100), (200);

> SELECT map('key', 200) AS a FROM s4 GROUP BY a HAVING a['key'] > 100;
  {"key":200}
  {"key":200}

Ograniczenia

W Databricks SQL i Databricks Runtime 20.0 i wyższych obsługiwana jest korelacja zagnieżdżona (podzapytanie odwołujące się do kolumn z zapytania zamykającego poza jego bezpośrednim rodzicem), z następującymi ograniczeniami:

  • Korelacja zagnieżdżona nie jest obsługiwana dla podzapytań w klauzuli HAVING .
  • LATERAL Podzapytania nie może być zagnieżdżone skorelowane. Jego zewnętrzne odniesienia muszą rozwiązywać się do bezpośrednio otaczającego zapytania.

W wersjach Databricks Runtime poniżej 20.0 korelacja jest ograniczona do jednego poziomu: podzapytanie może odwoływać się tylko do kolumn z zapytania, które je bezpośrednio otacza.

Przykłady

-- Differentiating columns and fields
> SELECT a FROM VALUES(1) AS t(a);
 1

> SELECT t.a FROM VALUES(1) AS t(a);
 1

> SELECT t.a FROM VALUES(named_struct('a', 1)) AS t(t);
 1

-- A column takes precedence over a field
> SELECT t.a FROM VALUES(named_struct('a', 1), 2) AS t(t, a);
 2

-- Implict lateral column alias
> SELECT c1 AS a, a + c1 FROM VALUES(2) AS T(c1);
 2  4

-- A local column reference takes precedence, over a lateral column alias
> SELECT c1 AS a, a + c1 FROM VALUES(2, 3) AS T(c1, a);
 2  5

-- A scalar subquery correlation to S.c3
> SELECT (SELECT c1 FROM VALUES(1, 2) AS t(c1, c2)
           WHERE t.c2 * 2 = c3)
    FROM VALUES(4) AS s(c3);
 1

-- A local reference takes precedence over correlation
> SELECT (SELECT c1 FROM VALUES(1, 2, 2) AS t(c1, c2, c3)
           WHERE t.c2 * 2 = c3)
    FROM VALUES(4) AS s(c3);
  NULL

-- An explicit scalar subquery correlation to s.c3
> SELECT (SELECT c1 FROM VALUES(1, 2, 2) AS t(c1, c2, c3)
           WHERE t.c2 * 2 = s.c3)
    FROM VALUES(4) AS s(c3);
 1

-- Correlation from an EXISTS predicate to t.c2
> SELECT c1 FROM VALUES(1, 2) AS T(c1, c2)
    WHERE EXISTS(SELECT 1 FROM VALUES(2) AS S(c2)
                  WHERE S.c2 = T.c2);
 1

-- Nested correlation: the innermost EXISTS references t1.a from the outermost query
> CREATE OR REPLACE TEMPORARY VIEW t1(a) AS VALUES(1), (2), (3);
> CREATE OR REPLACE TEMPORARY VIEW t2(b) AS VALUES(1), (2);
> CREATE OR REPLACE TEMPORARY VIEW t3(c) AS VALUES(2), (3);

> SELECT a FROM t1
    WHERE EXISTS(SELECT 1 FROM t2
                  WHERE t2.b = t1.a
                    AND EXISTS(SELECT 1 FROM t3
                                WHERE t3.c = t1.a));
 2

-- Attempt a lateral correlation to t.c2
> SELECT c1, c2, c3
    FROM VALUES(1, 2) AS t(c1, c2),
         (SELECT c3 FROM VALUES(3, 4) AS s(c3, c4)
           WHERE c4 = c2 * 2);
 [UNRESOLVED_COLUMN] `c2`

-- Successsful usage of lateral correlation with keyword LATERAL
> SELECT c1, c2, c3
    FROM VALUES(1, 2) AS t(c1, c2),
         LATERAL(SELECT c3 FROM VALUES(3, 4) AS s(c3, c4)
                  WHERE c4 = c2 * 2);
 1  2  3

-- Referencing a parameter of a SQL function
> CREATE OR REPLACE TEMPORARY FUNCTION func(a INT) RETURNS INT
    RETURN (SELECT c1 FROM VALUES(1) AS T(c1) WHERE c1 = a);
> SELECT func(1), func(2);
 1  NULL

-- A column takes precedence over a parameter
> CREATE OR REPLACE TEMPORARY FUNCTION func(a INT) RETURNS INT
    RETURN (SELECT a FROM VALUES(1) AS T(a) WHERE t.a = a);
> SELECT func(1), func(2);
 1  1

-- Qualify the parameter with the function name
> CREATE OR REPLACE TEMPORARY FUNCTION func(a INT) RETURNS INT
    RETURN (SELECT a FROM VALUES(1) AS T(a) WHERE t.a = func.a);
> SELECT func(1), func(2);
 1  NULL

-- Lateral alias takes precedence over correlated reference
> SELECT (SELECT c2 FROM (SELECT 1 AS c1, c1 AS c2) WHERE c2 > 5)
    FROM VALUES(6) AS t(c1)
  NULL

-- Lateral alias takes precedence over function parameters
> CREATE OR REPLACE TEMPORARY FUNCTION func(x INT)
    RETURNS TABLE (a INT, b INT, c DOUBLE)
    RETURN SELECT x + 1 AS x, x
> SELECT * FROM func(1)
  2 2

-- All together now
> CREATE OR REPLACE TEMPORARY VIEW lat(a, b) AS VALUES('lat.a', 'lat.b');

> CREATE OR REPLACE TEMPORARY VIEW frm(a) AS VALUES('frm.a');

> CREATE OR REPLACE TEMPORARY FUNCTION func(a INT, b int, c int)
  RETURNS TABLE
  RETURN SELECT t.*
    FROM lat,
         LATERAL(SELECT a, b, c
                   FROM frm) AS t;

> VALUES func('func.a', 'func.b', 'func.c');
  a      b      c
  -----  -----  ------
  frm.a  lat.b  func.c

Rozwiązywanie tabel i widoków

Identyfikator w odwołaniu do tabeli może być jednym z następujących:

Rozpoznawanie identyfikatora zależy od tego, czy jest on kwalifikowany:

  • Wykwalifikowany

    Jeśli identyfikator składa się w pełni z trzech elementów, takich jak catalog.schema.relation, to jest unikalny.

    Jeśli identyfikator składa się z dwóch części: schema.relation, jest on dodatkowo określany wynikiem SELECT current_catalog() w celu uczynienia go unikatowym.

    Jeśli schemat jest , sessionjest dodatkowo kwalifikowany i system interpretowany jako widok tymczasowy lub tabela tymczasowa. Jeśli schemat to global_temp, jest dodatkowo kwalifikowany i system interpretowany jako globalny widok tymczasowy w Databricks Runtime.

  • Niekwalifikowany

    1. typowe wyrażenie tabeli

      Jeśli odwołanie znajduje się w zakresie klauzuli WITH, dopasuj identyfikator do CTE, zaczynając od bezpośrednio zawierającej klauzuli WITH i przechodząc stamtąd na zewnątrz.

    2. Ścieżka przeszukiwania schematu

      W Databricks SQL i Databricks Runtime 19 i wyższych kwalifikuj relację z każdym schematem na ŚCIEŻCE, w kolejności, aż zostanie znalezione dopasowanie.

      • Brakujące katalogi lub schematy: Brakujące katalogi lub schematy na ścieżce są pomijane. Obiekt, dla którego użytkownik ma niewystarczające uprawnienia, nie jest pomijany; Azure Databricks zgłasza odpowiadający mu błąd.
      • Widoki i tabele tymczasowe: Widoki tymczasowe i tabele tymczasowe znajdują się w system.session, więc są osiągane zawsze, gdy system.session jest na .PATH
      • Tabele i widoki trwałe w obecnym schemacie: Tabele trwałe i widoki w aktualnym schemacie są dostępne przez wirtualny wpis.CURRENT_SCHEMA

      Ścieżka ta dotyczy niezastrzeżonych nazw relacji w zapytaniach i DML oraz nieustalonych nazw w zapytaniu będącym częścią instrukcji DDL.

      • Gdzie ścieżka ma zastosowanie:

        Context Użyta ścieżka
        Zapytania i DML (SELECT, INSERT, UPDATE, , DELETE) MERGE Ścieżka sesji
        Zapytanie CREATE TABLE AS Ścieżka sesji
        Zapytanie o trwałe CREATE VIEW PATH rejestrowany w czasie tworzenia
        Podmiot , CREATEDROP, ALTER, i podobne current_catalog.current_schema (nie sprawdza ścieżki)

      • Wcześniejsze wydania: W Databricks Runtime 18 i niższych, niezastrzeżona relacja, która nie jest CTE, jest rozwiązywana w stałej kolejności.

        1. Widok tymczasowy lub tabela tymczasowa

          Dopasuj identyfikator do dowolnego widoku tymczasowego lub tabeli tymczasowej zdefiniowanej w bieżącej sesji.

        2. trwała tabela

          W pełni określ identyfikator, poprzedzając go wynikiem SELECT current_catalog() i SELECT current_schema(), a następnie wyszukaj go jako trwałą relację.

Jeśli nie można rozwiązać odniesienia do żadnej tabeli, widoku lub CTE, Databricks zgłasza błąd TABLE_OR_VIEW_NOT_FOUND.

Zdobyta ścieżka

Widok trwały rejestruje ścieżkę sesji w momencie tworzenia. Późniejsze zapytania widoku rozstrzygają niezastrzeżone imiona na tej przejętej ścieżce, a nie na ścieżce sesji wywołującego. current_path() a current_schema() w tym zapytaniu nadal zwracają wartości sesji wywoływacza.

Przykłady

-- Setting up a scenario
> USE CATALOG spark_catalog;
> USE SCHEMA default;

> CREATE TABLE rel(c1 int);
> INSERT INTO rel VALUES(1);

-- An fully qualified reference to rel:
> SELECT c1 FROM spark_catalog.default.rel;
 1

-- A partially qualified reference to rel:
> SELECT c1 FROM default.rel;
 1

-- An unqualified reference to rel:
> SELECT c1 FROM rel;
 1

-- Add a temporary view with a conflicting name:
> CREATE TEMPORARY VIEW rel(c1) AS VALUES(2);

-- For unqualified references the temporary view takes precedence over the persisted table:
> SELECT c1 FROM rel;
 2

-- Temporary views cannot be qualified, so qualifiecation resolved to the table:
> SELECT c1 FROM default.rel;
 1

-- An unqualified reference to a common table expression wins even over a temporary view:
> WITH rel(c1) AS (VALUES(3))
    SELECT * FROM rel;
 3

-- If CTEs are nested, the match nearest to the table reference takes precedence.
> WITH rel(c1) AS (VALUES(3))
    (WITH rel(c1) AS (VALUES(4))
      SELECT * FROM rel);
  4

-- To resolve the table instead of the CTE, qualify it:
> WITH rel(c1) AS (VALUES(3))
    (WITH rel(c1) AS (VALUES(4))
      SELECT * FROM default.rel);
  1

-- For a CTE to be visible it must contain the query
> SELECT * FROM (WITH cte(c1) AS (VALUES(1))
                   SELECT 1),
                cte;
  [TABLE_OR_VIEW_NOT_FOUND] The table or view `cte` cannot be found.

Rozwiązywanie funkcji i procedur

Referencja rutynowa (wywołanie funkcji lub procedury) jest rozpoznawana przez obowiązkowy zestaw nawiasów końcowych.

Może to prowadzić do:

  • Wbudowana funkcja zapewniana przez Azure Databricks,
  • Tymczasowa funkcja zdefiniowana przez użytkownika w zakresie bieżącej sesji lub
  • Trwała funkcja lub procedura zdefiniowana przez użytkownika przechowywana w Hive Metastore lub Unity Catalog.

Rozwiązywanie nazwy rutyny zależy od tego, czy jest ona kwalifikowana:

  • Wykwalifikowany

    Jeśli nazwa jest w pełni kwalifikowana, składając się z trzech części: catalog.schema.routine, jest unikalna.

    Jeśli nazwa składa się z dwóch części: schema.routine, zostaje uzupełniona o wynik SELECT current_catalog(), aby była unikatowa.

    Jeśli schemat jest , sessionjest dodatkowo kwalifikowany i system interpretowany jako funkcja tymczasowa.

    Rutyna jest następnie wyszukiwana w katalogu.

  • Niekwalifikowany

    • Ścieżka wyszukiwania schematu: W Databricks SQL i Databricks Runtime 19 i wyższych kwalifikuj nazwę procedury z każdym schematem na PATH w kolejności i wybierz pierwsze dopasowanie.
    • Brakujące katalogi lub schematy: Brakujące katalogi lub schematy na ścieżce są pomijane. Obiekt, dla którego użytkownik ma niewystarczające uprawnienia, nie jest pomijany; Azure Databricks zgłasza odpowiadający mu błąd.
    • Gdzie występują procedury: Wbudowane funkcje skalarne i tabelowe działają w , system.builtinAI działa w system.ai, a funkcje tymczasowe w system.session.
    • Domyślna ścieżka: Domyślna PATH to system.session, potem system.builtin, potem system.ai, a następnie CURRENT_SCHEMA.

    Warning

    Funkcje tymczasowe o tej samej nazwie co funkcje wbudowane mają pierwszeństwo, ponieważ system.session są poprzedzone system.builtin na domyślnej ścieżce. Możesz zmienić kolejność ścieżki za pomocą SET PATH. Nie polegaj na tymczasowych funkcjach cieniujących wbudowane funkcje.

    • Gdzie ścieżka ma zastosowanie:

      Context Użyta ścieżka
      Nieokreślone nazwy procedur w zapytaniach i DML Ścieżka sesji
      Trzon funkcji zdefiniowanej przez użytkownika SQL PATH rejestrowany w czasie tworzenia
      Część procedury SQL SECURITY DEFINER PATH rejestrowany w czasie tworzenia, bez system.session
      Część procedury SQL SECURITY INVOKER Żywa ścieżka dzwoniącego
      Podmiot , CREATE FUNCTIONDROP FUNCTION, CREATE PROCEDURE, i podobne Aktualny schemat (nie wyszukiwanie ścieżki)

    • Wcześniejsze wersje: W Databricks Runtime 18 i niższych, Azure Databricks stosuje stałą kolejność priorytetów.

      1. Funkcja wbudowana

        Jeśli funkcja o tej nazwie istnieje wśród zestawu wbudowanych funkcji, zostanie wybrana ta funkcja.

      2. Funkcja tymczasowa

        Jeśli funkcja o tej nazwie istnieje wśród zestawu funkcji tymczasowych, zostanie wybrana ta funkcja.

      3. Zachowana funkcja

        W pełni kwalifikuj nazwę funkcji, poprzedzając wynikami SELECT current_catalog() i SELECT current_schema() i potraktuj ją jako funkcję trwałą.

Jeśli procedura nie może zostać rozwiązana, Azure Databricks zgłasza UNRESOLVED_ROUTINE błąd.

Zdobyta ścieżka

  • Funkcja zdefiniowana przez użytkownika SQL: Niekwalifikowane nazwy w treści są rozstrzygane względem ŚCIEŻKI zarejestrowanej w , CREATE FUNCTIONa nie ścieżki sesji wywoływacza. current_path() a current_schema() w tym ciele nadal zwracają wartości sesji wywoływacza.
  • Procedura z : SQL SECURITY DEFINERNiekwalifikowane nazwy są rozwiązywane względem ŚCIEŻKI zarejestrowanej w PROCEDURZE CREATE, z system.session pominięciem. current_path() w tym ciele wraca tą samą przejętą ścieżką.
  • Procedura z: SQL SECURITY INVOKERNiekwalifikowane nazwiska korzystają z ścieżki na żywo dzwoniącego.

Przykłady

> USE CATALOG spark_catalog;
> USE SCHEMA default;

-- Create a function with the same name as a builtin
> CREATE FUNCTION concat(a STRING, b STRING) RETURNS STRING
    RETURN b || a;

-- unqualified reference resolves to the builtin CONCAT
> SELECT concat('hello', 'world');
 helloworld

-- Qualified reference resolves to the persistent function
> SELECT default.concat('hello', 'world');
 worldhello

-- Create a persistent function
> CREATE FUNCTION func(a INT, b INT) RETURNS INT
    RETURN a + b;

-- The persistent function is resolved without qualifying it
> SELECT func(4, 2);
 6

-- Create a conflicting temporary function
> CREATE FUNCTION func(a INT, b INT) RETURNS INT
    RETURN a / b;

-- The temporary function takes precedent
> SELECT func(4, 2);
 2

-- To resolve the persistent function it now needs qualification
> SELECT spark_catalog.default.func(4, 3);
 6
  • Ostatnia aktualizacja o