From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: pg_dumpall renders ALTER TABLE for a view? |
Date: | 2022-12-15 17:15:13 |
Message-ID: | 3417783.1671124513@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com> writes:
> We found the root cause for an issue we encountered restoring a saved
> database stored with pg_dumpall, but during this investigation we realized
> that pg_dump/all renders `ALTER TABLE` statements for views, for example to
> convey ownership.
> I get that this is synonymous in most cases, except when there is an event
> trigger for `ALTER TABLE`, it ends up firing the event trigger for the
> views, and any event triggers expected to fire on `ALTER VIEW` statements
> do not fire.
> Is this something we can contribute a fix for, or is this some kind of
> necessary b/w compat issue that must remain?
We're not likely to change the fact that you're allowed to write ALTER
TABLE for this, so if your event triggers get broken by doing that
you'd best fix the event triggers.
I don't have any great objection to making pg_dump emit the more modern
spelling (I think ... you'd need to look into pg_restore to make sure
it's not assuming something in this area). But doing that won't
really remove the hazard.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michel Pelletier | 2022-12-15 17:31:30 | Re: pg_dumpall renders ALTER TABLE for a view? |
Previous Message | Michel Pelletier | 2022-12-15 16:54:05 | pg_dumpall renders ALTER TABLE for a view? |