On 08.07.26 18:48, Paul A Jungwirth wrote:
> On Tue, Jul 7, 2026 at 7:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> Paul A Jungwirth <pj@illuminatedcomputing.com> writes:
>>> On Tue, Apr 21, 2026 at 8:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> Checking this at parse time is completely the wrong thing.
>>>> The view could have gained (or lost) triggers by the time
>>>> it's executed.
>>
>>> But INSTEAD OF triggers are selected in the rewriter, which uses the
>>> same relcache snapshot as parse analysis. And a concurrent change
>>> can't sneak in different triggers, because that causes a relcache
>>> invalidation, so we redo the parse & rewrite phases.
>>
>> You have forgotten about views and rewrite rules. Those go to disk in
>> post-parser form, and will be rewritten only at execution sometime
>> later, *without* a re-parse.
>
> Ah yes, thank you! I should have been able to work that out.
>
> Here is another patch series. No code changes, but I inserted a new
> patch with tests showing that parse-time checking crashes, but
> rewrite-time and exec-time checking catches the forbidden statement.
> So the series is:
>
> v1: parse-time check, tests pass
> v2: add tests that crash the server
> v3: rewrite-time check: tests pass
> v4: exec-time check: tests pass
What do you want to do with these? Here you list them as four different
versions, but the attachments are four incremental patches of the same
version. Do you propose to apply all of them?
It seems we definitely do want the exec-time check. And I can see maybe
the parse-time check as an additional user-friendliness feature. But
maybe we don't need to check three times?
