Hi On Mon, Apr 20, 2026 at 12:56 AM Dean Rasheed <[email protected]> wrote:
> On Mon, 20 Apr 2026 at 01:33, SATYANARAYANA NARLAPURAM > <[email protected]> wrote: > > > > On Sun, Apr 19, 2026 at 3:42 AM Dean Rasheed <[email protected]> > wrote: > >> > >> 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? > > > > I'm not sure, but possibly because it used to be possible to turn a > table into a view by defining a SELECT rule on it, which could have > rendered a parse-time check insufficient. That's no longer the case > though, and we now have similar parse-time relkind tests elsewhere > (e.g., for MERGE). > > > Updated the patch to include a test case to reject view update with > WHERE CURRENT OF. > > > > That's already tested in portals.sql, which seems like a better place > for that test, since it's not related to virtual generated columns. I > don't think another test is necessary -- admittedly portals.sql only > tests DELETE, but the UPDATE code is the same, so I think the existing > test is sufficient. We don't obsessively try to achieve 100% coverage > in our tests. > Sounds good. Thanks for letting me know.
