Skip site navigation (1) Skip section navigation (2)

Re: Command Triggers, patch v11

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Thom Brown <thom(at)linux(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Command Triggers, patch v11
Date: 2012-03-08 22:24:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

Thom Brown <thom(at)linux(dot)com> writes:
> The message returned by creating a command trigger after create index
> is still problematic:

Fixed.  I'm attaching an incremental patch here, the github branch is
updated too.

> CREATE VIEW doesn't return schema:

Fixed, and as an added bonus I fixed the CREATE SEQUENCE oddity about
that too.

> No specific triggers fire when altering a conversion:

Couldn't reproduce, works here, added tests.

> No specific triggers fire when altering the properties of a function:


> No specific triggers fire when altering a sequence:

Couldn't reproduce, added tests.

> No specific triggers when altering a view:

Same again.

> The object name shown in specific triggers when dropping aggregates
> shows the schema name:
> Same for collations:
> Dropping functions shows the object name as the schema name:
> Same with dropping operators:
> ...and operator family:
> … and the same for dropping text search
> configuration/dictionary/parser/template.

Fixed in the attached (all of those where located at exactly the same
place, by the way, that's one fix).

> When dropping domains, the name of the domain includes the schema name:

I'm using format_type_be(objectId) so that int4 is integer and int8
bigint etc, but that's adding the schemaname. I didn't have time to look
for another API that wouldn't add the schemaname nor to add one myself,
will do that soon.

> I hadn't previously tested triggers against CLUSTER, REINDEX, VACUUM
> and LOAD, but have tested them now.

Cool :)

> When creating a trigger on REINDEX, I get the following message:


> Creating AFTER CLUSTER command triggers produce an error (as expected
> since it's not supported), but AFTER REINDEX only produces a warning.
> These should be the same, probably both an error.


> VACUUM doesn't fire a specific command trigger:

I though it was better this way, I changed my mind and completed the code.

> REINDEX on a table seems to show no schema name but an object name for
> specific triggers:

Still on the TODO.

> When REINDEXing an index rather than a table, the table's details are
> shown in the trigger.  Is this expected?:

Yeah well.  Will see about how much damage needs to be done in the
current APIs, running out of steam for tonight's batch.

> REINDEXing the whole database doesn't fire specific command triggers:

We don't want to because REINDEX DATABASE is managing transactions on
its own, same limitation as with AFTER VACUUM and all.  Will have a look
at what it takes to document that properly.

> Documentation:


Thom Brown <thom(at)linux(dot)com> writes:
> I've also since found that if I issue a VACUUM, CLUSTER or REINDEX on
> a read-only standby, the BEFORE ANY COMMAND trigger fires.  I don't
> think any trigger should fire on a read-only standby.

Well I'm not sold on that myself (think pl/untrusted that would reach
out to the OS and do whatever is needed there).  You can even set the
session_replication_role GUC to replica and only have the replica
command triggers fired.

Dimitri Fontaine     PostgreSQL : Expertise, Formation et Support

Attachment: more-cmd-trigger-fixes.patch
Description: text/x-patch (33.1 KB)

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2012-03-09 00:19:19
Subject: Re: poll: CHECK TRIGGER?
Previous:From: Pavel StehuleDate: 2012-03-08 22:15:20
Subject: Re: poll: CHECK TRIGGER?

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group