Re: [HACKERS] Improvements in psql hooks for variables
От | Daniel Verite |
---|---|
Тема | Re: [HACKERS] Improvements in psql hooks for variables |
Дата | |
Msg-id | d1e8b35d-32a7-4722-b98f-e1db46b90777@manitou-mail.org обсуждение исходный текст |
Ответ на | Re: [HACKERS] Improvements in psql hooks for variables ("Daniel Verite" <daniel@manitou-mail.org>) |
Ответы |
Re: [HACKERS] Improvements in psql hooks for variables
|
Список | pgsql-hackers |
I wrote: > This would allow the hook to distinguish between initialization and > unsetting, which in turn will allow it to deny the \unset in the > cases when it doesn't make any sense conceptually (like AUTOCOMMIT). I notice that in the commited patch, you added the ability for DeleteVariable() to reject the deletion if the hook disagrees. + { + /* Allow deletion only if hook is okay with NULL value */ + if (!(*current->assign_hook) (NULL)) + return false; /* message printed by hook */ But this can't happen in practice because as mentioned just upthread the hook called with NULL doesn't know if the variable is getting unset or initialized, so rejecting on NULL is not an option. Attached is a proposed patch to add initial values to SetVariableAssignHook() to solve this problem, and an example for \unset AUTOCOMMIT being denied by the hook. As a side effect, we see all buit-in variables when issuing \set rather than just a few. Does it make sense? Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: