On Fri, 17 Apr 2026 at 21:04, SATYANARAYANA NARLAPURAM
<satyanarlapuram@gmail.com> wrote:
>
> Hi hackers,
>
> UPDATE and DELETE with WHERE CURRENT OF cursor fail on tables that have virtual generated columns, erroring with
"WHERECURRENT OF on a view is not implemented" even though the target is a regular table, not a view.
>
Nice catch!
> Analysis:
> The bug stems from replace_rte_variables_mutator() in rewriteManip.c, which unconditionally errors on any
CurrentOfExprreferencing the target relation. This appears to a check designed for view rewriting, where WHERE CURRENT
OFcannot be translated through a view. However, virtual generated column (VGC) expansion also routes through this
mutator.The rewriter's expand_generated_columns_internal() calls ReplaceVarsFromTargetList(), and the planner's
expand_virtual_generated_columns()calls pullup_replace_vars(), which calls replace_rte_variables(). Since virtual
generatedcolumns use same mutator, while expanding virtual generated columns returns the same error even though the
tableis not a view and the cursor position is perfectly valid.
>
> The fix adds bool error_on_current_of to replace_rte_variables_context. The existing replace_rte_variables() is
refactoredinto a static replace_rte_variables_internal() that accepts the flag, with two public wrappers:
replace_rte_variables()(passes true, preserving existing behavior) and replace_rte_variables_ext() (exposes the flag).
Thesame pattern is applied to ReplaceVarsFromTargetList() / ReplaceVarsFromTargetListExtended(). In
replace_rte_variables_mutator(),the CurrentOfExpr error is now conditional on context->error_on_current_of. The two VGC
expansioncall sites pass false; all other callers pass true. The down side of this approach is that it is adding
additionalpublic API.
>
Hmm, it seems to me that a much simpler fix is to check for use of
WHERE CURRENT OF on a view at parse time, and throw the error there.
Then the problematic rewriter check can simply be removed, as in the
attached v2 patch.
Regards,
Dean
