From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Flo <fluancefg(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Can't restore view with pg_restore |
Date: | 2017-05-30 13:36:42 |
Message-ID: | 10091.1496151402@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Flo <fluancefg(at)gmail(dot)com> writes:
> I was not able to find any explicit trigger creation related to
> bmv_visits_list, but I have found where the issue comes from.
> ...
> So basicaly, the extension pglogical adds the table to its list of known
> tables and set a trigger to it.
Hm, I don't know much about pglogical. Does it automatically add a
trigger to every new table without user intervention? If so, that's
kinda broken.
> What I don't know and don't understand is why it doesn't happen with the
> other views.
Probably because they don't have to be split into two steps like this one
is. I'm guessing that pglogical has a hook installed that sees the CREATE
TABLE, thinks this is going to be a regular table, and gloms onto it
before it's converted to a view.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-05-30 14:03:23 | Re: BUG #14679: Inconsistent/wrong behavior of pg_trigger_depth when used with DEFERRED CONSTRAINTS |
Previous Message | Marko Tiikkaja | 2017-05-30 12:46:55 | Re: BUG #14676: neqsel is NULL dumb |