Re: [BUG]: WHERE CURRENT OF cursor fail on tables that have virtual generated columns

HI,

On Sun, Apr 19, 2026 at 3:42 AM Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
wrote:

> On Fri, 17 Apr 2026 at 21:04, SATYANARAYANA NARLAPURAM
> <satyanarlapuram(at)gmail(dot)com> wrote:
> >
> > Hi hackers,
> >
> > UPDATE and DELETE with WHERE CURRENT OF cursor fail on tables that have
> virtual generated columns, erroring with "WHERE CURRENT 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 CurrentOfExpr referencing the target
> relation. This appears to a check designed for view rewriting, where WHERE
> CURRENT OF cannot 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
> generated columns use same mutator, while expanding virtual generated
> columns returns the same error even though the table is 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 refactored into 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). The same
> 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 expansion call sites pass false; all other callers pass true.
> The down side of this approach is that it is adding additional public 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.
>

This patch looks simple and neat, is there any reason why it was done
differently earlier?

> Then the problematic rewriter check can simply be removed, as in the
> attached v2 patch.
>

I reviewed the patch, and it addresses the original bug and other existing
tests.
I verified it rejects the view with WHERE CURRENT OF on update and delete.

Updated the patch to include a test case to reject view update with WHERE
CURRENT OF.

Thanks,
Satya