Re: Command Triggers, patch v11

From: Thom Brown <thom(at)linux(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Command Triggers, patch v11
Date: 2012-02-26 19:49:12
Message-ID: CAA-aLv5tuh9RKNmgCnxWr8jdUOi0EeYix32GC2Pxvr=7DUD+JQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 26 February 2012 14:12, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
> 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.

Which tests? The FTS Config test was what I posted before. I haven't
gone to any great effort to set up tests for each command. I've just
been making them up as I go along.

>> 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?

Well considering there are commands that exist which we don't allow
triggers on, it seems weird to support triggers on commands which
aren't implemented. DROP ASSERTION doesn't appear anywhere else in
the documentation, so I can't think of how supporting a trigger for it
could be useful.

>> 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.

So would the fix cover many cases at once?

>> 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.

Being killed by a captain does make things more difficult, yes.

--
Thom

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter van Hardenberg 2012-02-26 20:22:31 Re: psql \i tab completion initialization problem on HEAD
Previous Message Magnus Hagander 2012-02-26 19:24:08 Checkpointer vs pg_stat_bgwriter