Horton

Thread

Commits

  1. Add some tests for CREATE OR REPLACE VIEW with column additions

  1. Funny behavior in event trigger code with CREATE OR REPLACE VIEW and column additions

    Michael Paquier <michael@paquier.xyz> — 2026-02-27T07:25:41Z

    Hi all,

While removing some dust from my stack of patches, I have bumped into
a weird interaction with CREATE OR REPLACE VIEW due to
AT_AddColumnToView:
CREATE VIEW one_view AS SELECT * FROM one;
-- Adds some columns.
CREATE OR REPLACE VIEW one_view AS SELECT * FROM one, two;

The funny behavior is with the second VIEW query, that has the idea to
stack twice a ViewStmt in event triggers: once in a
EventTriggerCollectSimpleCommand() and a second time in
EventTriggerAlterTableEnd().  Now, why would the second one be
stacked?  Well, EventTriggerAlterTableEnd() would add it because it
has some AT_AddColumnToView subcommands.

First, I was wondering if we should tweak EventTriggerAlterTableEnd()
so as subcommands that add columns to a view should not be duplicated,
applying some filtering.  However, at the end, I have come to accept
the fact that event triggers are a representation at SQL level of the
internal structures of these commands.  Hence, the current code is
fine, still we had better have some tests to document that.  And we
don't do that now.

This issue has come up while looking at a portion of my sequence AM
patch, where I was not sure what the right representation should be in
event triggers.  I just noticed that column additions for views do
already the same thing.

So, please find attached a small-ish patch to close the gap with a few
tests:
- One thing for event_trigger.sql, with column additions for view, to
check the collection.
- One for test_ddl_deparse, that shows the stack of both a "simple"
and an "alter table".

Thoughts or comments?
--
Michael

  2. Re: Funny behavior in event trigger code with CREATE OR REPLACE VIEW and column additions

    Michael Paquier <michael@paquier.xyz> — 2026-03-04T01:13:03Z

    On Fri, Feb 27, 2026 at 04:25:41PM +0900, Michael Paquier wrote:
> Thoughts or comments?

As it would be a waste to not track this old behavior in the tests, I
have applied that.  (Spoiler alert: I broke it accidently while
playing with this area of the code.)
--
Michael