У нотатці від 2 листопада 2009 року йдеться про передавання користувацького контексту в PostgreSQL зі старої «Корпорація 2». Ідея полягала в тому, щоб код у базі міг отримати відомості про поточного користувача та магазин. Назви параметрів починалися з usrvar..
Це контекст підключення до бази, а не звичайні змінні середовища операційної системи. Для підтримки старої інсталяції важливо розрізняти серверні можливості PostgreSQL і власні функції прикладної системи.
Як налаштовували простір імен у старій версії
У тодішньому postgresql.conf вказували такий рядок:
custom_variable_classes = 'usrvar'До PostgreSQL 9.2 параметр custom_variable_classes визначав допустимі префікси користувацьких налаштувань. Ім’я складалося з префікса, крапки та назви параметра. Сам префікс не створював ані користувача бази, ані його права доступу.
П’ять параметрів із початкової нотатки
Нижче збережено всі назви й первісні коментарі. Рядки значень у джерелі незавершені, тому копіювати цей блок у конфігурацію як готовий приклад не можна:
usrvar.myuserid='; # id пользователя
usrvar.myusername='; # Имя пользователя
usrvar.myroleid='; # id пользователя
usrvar.myrolename='; # Имя прав
usrvar.magid='; # id магазина| Назва | Що можна встановити з нотатки |
|---|---|
usrvar.myuserid | Коментар описує ідентифікатор користувача. |
usrvar.myusername | Ім’я користувача. |
usrvar.myroleid | Назва натякає на роль, але початковий коментар повторює «id пользователя». Точне значення визначає реалізація системи; вважати його підтвердженим ID ролі лише за назвою не можна. |
usrvar.myrolename | Авторський коментар — «Имя прав»; точний зв’язок із моделлю ролей у нотатці не описаний. |
usrvar.magid | Ідентифікатор магазину. |
Для відновлення саме цієї конфігурації потрібні типи та допустимі значення параметрів у відповідній версії програми. Незакрита лапка не означає, що правильне значення обов’язково порожнє.
Що робили set_var і get_var
Початкова нотатка показує два виклики: запис імені та його читання.
select set_var('myusername', 'rudjuk');
select get_var('myusername');set_var і get_var тут є функціями прикладного рішення. Їхні визначення не наведено, тому не можна стверджувати, як саме вони додають префікс, перевіряють значення чи зберігають стан. Це не назви стандартних функцій керування параметрами PostgreSQL.
Під час перенесення треба знайти визначення цих функцій у вихідному коді або схемі старої бази та перевірити місця їх виклику. Самої заміни назви функції недостатньо, якщо стара обгортка додатково перевіряла дані чи обробляла відсутнє значення.
Що змінилося починаючи з PostgreSQL 9.2
У випуску 9.2 custom_variable_classes вилучили. У сучасних версіях PostgreSQL приймає користувацькі імена з двох частин без цього списку префіксів. Старий рядок не потрібно переносити до нового postgresql.conf.
Для звичайного навчального прикладу можна використати стандартні функції set_config і current_setting. Наступний код демонструє механіку PostgreSQL 17, а не відтворює приховану реалізацію старих функцій «Корпорація 2»:
BEGIN;
SELECT set_config('usrvar.myusername', 'demo_user', true);
SELECT current_setting('usrvar.myusername');
ROLLBACK;Усередині цієї транзакції другий запит поверне demo_user. Аргумент true обмежує дію встановленого значення поточною транзакцією; false задає рівень сеансу. Результат після завершення транзакції залежить також від попереднього стану параметра, тому для перевірки прикладу читаємо його до ROLLBACK.
Для необов’язкового параметра в PostgreSQL 17 можна виконати current_setting('usrvar.optional_context', true): якщо налаштування взагалі відсутнє, результатом буде NULL. Порожній рядок і відсутній параметр потрібно обробляти окремо.
Що перевірити в прикладній системі
- Зіставити кожну назву з реальним полем і місцем використання; особливо уточнити суперечливий коментар до
myroleid. - Встановлювати контекст у тому самому підключенні, де виконуються залежні від нього запити.
- За наявності пулу підключень визначити межі транзакції та очищення стану, щоб контекст попереднього запиту не переходив до наступного користувача.
- Окремо перевірити прикладні права та ролі PostgreSQL: довільне текстове значення параметра саме по собі не підтверджує особу й не надає прав.
- Перевірити сценарії відсутнього, порожнього та некоректного значення, а також відкат транзакції.
Так можна зберегти задум історичної реалізації й водночас чітко визначити, які частини підтверджені нотаткою, а які потрібно встановити за кодом конкретної інсталяції.
Джерела: налаштування користувацьких класів у PostgreSQL 9.0, зміни у випуску 9.2, користувацькі параметри PostgreSQL 17, set_config і current_setting.
Немає коментарів:
Дописати коментар