On Sun, Nov 27, 2016 at 1:59 PM, Artur Zakirov <a.zaki...@postgrespro.ru> wrote: > Thank you for answers. > > 2016-11-19 21:28 GMT+03:00 Michael Paquier <michael.paqu...@gmail.com>: >> On Thu, Nov 17, 2016 at 1:17 PM, Alvaro Herrera >> <alvhe...@2ndquadrant.com> wrote: >>> It's a bug. You're right that we need to handle the object class >>> somewhere. Perhaps I failed to realize that tsconfigs could get >>> altered. >> >> It seems to me that the thing to be careful of here is how a new >> OBJECT_TSCONFIGURATIONMAP should use ObjectAddress. It does not seem >> that complicated, but it needs some work. >> -- >> Michael > > After some investigation it seems to me that OBJECT_TSCONFIGURATIONMAP > can't be added for pg_ts_config_map. Because this catalog hasn't Oids. > > But this bug can be easily fixed (patch attached). I think in > AlterTSConfiguration() TSConfigRelationId should be used instead of > TSConfigMapRelationId. Secondly, in ProcessUtilitySlow() we can use > commandCollected = true. Because configuration entry is added in > EventTriggerCollectAlterTSConfig() into > currentEventTriggerState->commandList. > > This patch only fixes the bug. But I think I also can do a patch which > will give pg_ts_config_map entries with > pg_event_trigger_ddl_commands() if someone wants. It can be done using > new entry in the CollectedCommandType structure maybe.
You might need to add this patch to https://commitfest.postgresql.org/ so that it doesn't get forgotten. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers