On Fri, Jan 2, 2026 at 5:25 PM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>
> + char *trigcomment; /* comment to apply to trigger, or NULL */
> No other Create*Stmt has a comment field. Comments seem to be handled through separate CommentStmt creation.
>
See CreateStatsStmt.stxcomment, IndexStmt.idxcomment.
We need CreateTrigStmt.trigcomment, because if INCLUDING COMMENTS is specified,
CreateTrigStmt.trigcomment can be used to hold the source object's comments.
> Some nitpicking about tests:
> 1. INSTEAD OF triggers on views - The error is tested, but should also test that statement-level VIEW triggers work
ok. test added.
> 2. Triggers on partitioned tables - What happens when you LIKE a partitioned table? Are partition triggers cloned?
no. only the trigger on the partitioned table itself will be cloned.
see tests ``create table parted_constr_copy (like parted_constr
including all);``
> 3. Cross-schema trigger functions - The function name reconstruction handles schemas, but is it tested?
>
ok. test added.
> + funcname = list_make2(makeString(schemaname),makeString(NameStr(procform->proname)));
> Other NameStr() are pstrdup()'d, maybe let's pstrdup() this too?
>
ok.
> + /* Reconstruct trigger old transition table */
> Second instance of this comment is wrong.
>
ok.
> + PG_KEYWORD("triggers", TRIGGERS, UNRESERVED_KEYWORD, BARE_LABEL)
> Won't this break some user SQLs?
it's marked as an un-reserved word, so it won't break any SQL, i think.
v4-0001, v4-0002 was removed, as Robert said in [1], now I am using
the same ugly
hack consistently, now code is more aligned with INCLUDING INDEXES, INCLUDING
STATISTICS.
pstrdup have been used in more places in generateClonedTriggerStmt.
--
jian
https://www.enterprisedb.com/
