On 08.07.26 18:48, Paul A Jungwirth wrote:
On Tue, Jul 7, 2026 at 7:07 PM Tom Lane <[email protected]> wrote:
Paul A Jungwirth <[email protected]> writes:
On Tue, Apr 21, 2026 at 8:24 AM Tom Lane <[email protected]> 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?
