Hi, On March 16, 2020 1:22:18 PM PDT, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >Andres Freund <andres@xxxxxxxxxxx> writes: >> On 2020-03-16 12:44:53 -0700, Andres Freund wrote: >>> On 2020-03-15 20:11:18 -0400, Tom Lane wrote: >>>> I wonder if we should change it to allow that when >>>> allow_system_table_mods is true? This isn't the first time we've >>>> seen people need to be able to do surgery on a toast table. > >>> I'd be mildly in favor. But it's considerably more than just the >>> executor check that'd need to change. We don't the right thing for >toast >>> relations in plenty places right now, because we just check for >>> RELKIND_RELATION - which will break junkvars etc. > >> Hm, and I wonder if there could be problems with >> HeapTupleSatisfiesToast() too? It doesn't really forsee much DML >being >> done. > >We've always allowed people to select from toast tables, so if there >are planner or executor problems with that, I'd think they'd mostly be >bugs that need fixed anyway. Your point about HeapTupleSatisfiesToast >is better though. The logic to add/extract junkvars for updated/deleted tables, as well as other parts of the modification code paths, weren't exposed so far though. I've tried allowing updates/deletes before (at least deletes are needed to e.g handle duplicate values), I'm fairly confident that the junkvar issue is real. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
