Re: Command Triggers, patch v11

Thanks for your further testing!

Thom Brown <thom(at)linux(dot)com> writes:
> Further testing reveals a problem with FTS configurations when using
> the example function provided in the docs:

Could you send me your tests so that I add them to the proper regression
test? I've been lazy on one or two object types and obviously that's
where I have to check some more.

> Also command triggers for DROP CONVERSION aren't working. A glance at
> pg_cmdtrigger shows that the system views the command as "DROP
> CONVERSION_P".

That's easy to fix, that's a typo in gram.y. I'm not seeing other ones
like this though.

- | DROP CONVERSION_P { $$ = "DROP CONVERSION_P"; }
+ | DROP CONVERSION_P { $$ = "DROP CONVERSION"; }

> What is DROP ASSERTION? It's showing as a valid command for a command
> trigger, but it's not documented.

It's a Not Implemented Feature for which we have the grammar support to
be able to fill a standard compliant checkbox, or something like that.
It could be better for me to remove explicit support for it in the
command triggers patch?

> I've noticed that ALTER <object> name OWNER TO role doesn't result in
> any trigger being fired except for tables.
>
> ALTER OPERATOR FAMILY .... RENAME TO ... doesn't fire command triggers.
>
> ALTER OPERATOR CLASS with RENAME TO or OWNER TO doesn't fire command
> triggers, but with SET SCHEMA it does.

It seems I've forgotten to add some support here, that happens in
alter.c and is easy enough to check and complete, thanks for the
testing.

> And there's no command trigger available for ALTER VIEW.

Will add.

> I'll hold off on testing any further until a new patch is available.

That should happen soon. Ah, the joys of coding while kids are at home
thanks to school holidays. I can't count how many times I've been killed
by a captain and married to a princess while writing that patch, sorry
about those hiccups here.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support