ts=# CREATE INDEX ON t(i) ;
CREATE INDEX
ts=# DROP INDEX t_i_idx ;
NOTICE: 00000: drop_trigger
LOCATION: exec_stmt_raise, pl_exec.c:3748
DROP INDEX
ts=#
ts=# \d t
Table "public.t"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
i | integer | | |
ts=# SELECT COUNT(1) FROM pg_trigger WHERE tgrelid='t'::regclass;
count | 0
It's not specific to the index name, since it can happen multiple times for
each index on that table:
ts=# DROP index t_i_idx2;
NOTICE: drop_trigger
DROP INDEX
ts=# DROP index t_i_idx1;
NOTICE: drop_trigger
DROP INDEX
ts=#
I looked in pg_depend, but didn't see any trigger with dependency (but maybe
not doing it right):
ts=# SELECT objid::regclass, * FROM pg_depend WHERE refobjid='t_i_idx'::regclass;
(0 rows)
This doesn't occur on new tables, just this one..
"ts" is an unused database on our development VM which which I found myself
connecting to by habbit (it's the name of most of our customer DBs). I
anticipate this may be result of catalog cruftiness resulting from upgrades
from 11dev through each of the betas.
Specifically this would've been the instance being upgraded when I wrote:
https://www.postgresql.org/message-id/flat/20180529171015.GA22903%40telsasoft.com
I don't know what else to look at, but wonder if there's any use in debugging
this further ?
Justin
