Процедурні мови PostgreSQL - відмінності між PL / pgSQL та SQL

Чи може хто-небудь, будь ласка, узагальнити відмінності між:

http://www.postgresql.org/docs/9.1/static/xfunc-sql.html

і

http://www.postgresql.org/docs/9.1/static/plpgsql.html

?

Основні моменти:

• концептуальні відмінності
• враховуючи сімейство проблем, зручність використання
• політичні питання

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

• Використовуйте представлення, де це можливо
• Якщо представлення не підходить, використовуйте функцію SQL
• Якщо функція SQL не підходить, використовуйте PL / PgSQL.
• Якщо PL / PgSQL є занадто обмеженим або недостатньо виразним, використовуйте PL / Perl, PL / Python, PL / V8, PL / Java або будь-яку іншу вашу перевагу
• ... і там, де жоден спеціаліст не виконає цю роботу, скористайтеся зовнішньою програмою, можливо, LISTENі NOTIFYпоговоріть з нею.

Дуже часто перегляду достатньо, коли ви вважаєте, що потрібна функція. Навіть якщо це надзвичайно дорого для SELECTцілого перегляду, WHEREпункти запиту, що посилаються на перегляд, зазвичай висуваються в поле перегляду і можуть призводити до дуже різних планів запитів. У мене часто спостерігалися значні поліпшення продуктивності від перетворення функцій SQL в представлення.

Основний час, коли ви виявите, що ви не можете використовувати представлення даних, і слід враховувати функцію SQL, коли:

• Параметри, які не можуть бути виражені простими WHEREпропозиціями, потрібні, як параметр у WITHвиразі
• Вам потрібно встановити бар'єр безпеки через SECURITY DEFINERфункцію, і security_barrierперегляди в PostgreSQL 9.2 і вище не є достатніми для ваших потреб;
• Вам потрібні параметри, які оптимізатором не висуваються підпункти перегляду і хочуть керувати ним більш безпосередньо; або
• Парам багато, або багато повторень парам, тому запитувати запит як перегляд недоцільно.

Для більшості цих завдань звичайна функція SQL працює чудово і її часто читати легше, ніж PL / PgSQL. Функції SQL, оголошені STABLEабо IMMUTABLE(а також не оголошені STRICTабо SECURITY DEFINER), також можуть бути включені в оператор виклику. Це позбавляється від накладних викликів функцій, а також може іноді призвести до величезних переваг від продуктивності, коли умова WHERE у функції виклику оптимізатором підштовхується до функції SQL. Використовуйте функції SQL, коли їх достатньо для виконання завдання.

Основні функції SQL не виконають цю роботу, коли вам потрібно багато логіки. Якщо / then / else операції, які ви не можете виразити як CASEзаяви, багато повторного використання обчислених результатів, нарощування значень з фрагментів, обробка помилок тощо. Виберіть PL / PgSQL, коли ви не можете використовувати функції SQL або вони погано підходять, наприклад:

• Динамічний SQL та динамічний DDL через EXECUTEоператор
• Коли ви хочете RAISEпомилки / попередження для журналів або клієнта
• Коли вам потрібно обробляти винятки - ви можете захоплювати та обробляти помилки EXCEPTIONблоками замість того, щоб вся транзакція закінчувалася помилкою
• Складна умовна логіка, яка не CASE ... WHENдуже підходить
• Багато повторного використання обчислених значень, які ви не можете вписати в WITHта CTE
• Побудова динамічних записів
• Вам потрібно виконати дію після створення набору результатів

З загальними табличними виразами (CTE), особливо записуються CTE, і WITH RECURSIVEя вважаю, що я використовую PL / PgSQL набагато менше, ніж я звик, тому що SQL настільки більш виразний та потужний. Зараз я набагато більше використовую представлення та прості функції SQL. Варто пам’ятати, що прості функції SQL можуть містити більше одного оператора; останнє твердження - результат функції.

plpgsqlце повноцінна процедурна мова зі змінними, циклічними конструкціями тощо. SQLФункція - це просто підзапит. Функція SQL, якщо вона оголошена STABLEабо IMMUTABLEне також оголошена STRICT, часто може бути вбудована в запит виклику, як ніби вона виписана на кожну посилання.