|From:||"Daniel Verite" <daniel(at)manitou-mail(dot)org>|
|To:||"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||"Rahila Syed" <rahilasyed90(at)gmail(dot)com>,"Stephen Frost" <sfrost(at)snowman(dot)net>,"Ashutosh Bapat" <ashutosh(dot)bapat(at)enterprisedb(dot)com>,"pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>,"Andrew Dunstan" <andrew(at)dunslane(dot)net>|
|Subject:||Re: Improvements in psql hooks for variables|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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
+ /* 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?
PostgreSQL-powered mailer: http://www.manitou-mail.org
|Next Message||Corey Huinker||2017-01-31 17:16:51||Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)|
|Previous Message||Alvaro Herrera||2017-01-31 17:10:01||Re: Patch: Write Amplification Reduction Method (WARM)|