Чи можу я покластися на функції, що виконуються спочатку в SQL

Будь ласка, врахуйте наступний сценарій:

create or replace function f(p_limit in integer) return integer as
begin
  set_global_context ('limit', p_limit);
  return p_limit;
end;
/

create view v as 
select level as val from dual connect by level<=sys_context('global_context','limit');

select f(2), v.* from v;

/*
F(2)                   VAL                    
---------------------- ---------------------- 
2                      1                      
2                      2                      
*/

select f(4), v.* from v;

/*
F(4)                   VAL                    
---------------------- ---------------------- 
4                      1                      
4                      2                      
4                      3                      
4                      4                      
*/

Чи можу я розраховувати на f(x)те, що він буде виконаний до того, як контекст буде прочитаний всередині перегляду, як це було у цьому тестовому випадку, запущеному 10.2?

Ні.

Якщо ви перезапишете свій погляд з фільтруванням контексту у відповідність до пункту where (замість підключення by), ви отримаєте раніше встановлене значення для контексту:

create table t as 
 select rownum r from dual connect by level <= 10;

create or replace view v as 
  select r val from t where r <=sys_context('global_context','limit');

select f(2), v.* from v;

F(2) VAL
---- ---
   2   1 
   2   2 

select f(4), v.* from v;

F(4) VAL
---- ---
   4   1 
   4   2 

select f(4), v.* from v;

F(4) VAL
---- ---
   4   1 
   4   2 
   4   3 
   4   4 

Оскільки стаття де оцінюється до вибору стовпців, значення, передане функції, не встановлюється, поки не буде прочитаний контекст. Розташування виклику sys_context у вашому запиті (виберіть, де, групувати тощо) буде впливати саме тоді, коли встановлено це значення.

Взагалі кажучи, ви не можете безпечно припускати нічого про порядок, в якому ваші СУБД будуть робити речі під час оцінки одного оператора SQL. Ось чому багато СУБД не дозволять функціям, які використовуються таким чином, мати побічні ефекти (тобто MSSQL не дозволить функціям встановлювати глобальний стан / стан з'єднання, який ви там робите, або змінювати вміст таблиці). Серія висловлювань повинна бути виконана таким чином, що має сенс від одного кроку до іншого (тобто вони виконуються послідовно, або таким чином, що ви не можете сказати, що їх не було), але в межах одного твердження планувальник запитів має вільне правління, доки воно не вводить неоднозначність там, де його вже немає (у вашому прикладі неоднозначність вже існує, оскільки функція має побічний ефект впливає на вигляд).

Якби планувальник запитів був досить яскравим, щоб виявити, що на подання впливають побічні ефекти функції, що це зробить, якщо ви приєднаєтесь до іншого представлення, яке викликало цю функцію потенційно з різними вхідними значеннями? Це може досить швидко стати дуже волохатим - така річ, чому загалом, в будь-якому контексті програмування, функції не повинні мати наслідків, що перевищують їх власні результати.

У цьому конкретному прикладі я б сказав, що навряд чи f (x) буде викликано першим, оскільки це є "він" частиною висловлення: результат, встановлений з подання, можливо, буде отриманий перед будь-якими функціями в межах список стовпців для повернення оцінюється. Звичайно, це буде різнитися залежно від використовуваної СУБД: Я не експерт Oracle, а ваші результати тестування показують, що функція, як видається, викликається спочатку в цих випадках. Але я б насторожено покладався на порядок виконання в будь-якому одному викладі SQL все одно - навіть якщо він завжди працює так, як ви зараз очікуєте, він може не робити цього в майбутніх редакціях (якщо це не буде офіційно зафіксовано десь, виконання завжди буде йти цей шлях навколо).

Документація лише обіцяє, що "Оптимізатор спочатку максимально повно оцінює вирази та умови, що містять константи". ( 10.2 , 11.2 ). Ви не впевнені, що він спочатку оцінить якийсь конкретний вираз або що він не буде змінювати цей порядок час (новий патч-рівень у тому ж випуску?).