Re: Command Triggers, patch v11

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Thom Brown <thom(at)linux(dot)com>, 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-09 17:29:55
Message-ID: m2eht1ptrg.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I'm not convinced. Right now, it's fairly useless - all the triggers
> could possibly do is throw an error, and an error is going to get
> thrown anyway, so it's only a question of which error message the user
> will see. But we discussed before the idea of adding a capability for
> BEFORE triggers to request that the actual execution of the command
> get skipped, and then it's possible to imagine this being useful.
> Someone could even use a command trigger that detects which machine
> it's running on, and if it's the standby, uses dblink to execute the
> command on the master, or something crazy like that. Command triggers
> could also be useful for logging all attempts to execute a particular
> command, which is probably still appropriate on the standby.

There are some other use cases, like using plsh to go apt-get install an
extension's package when you see the master just created it, so that
your read only queries on the hot standby have a chance of loading the
code you need.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2012-03-09 17:38:28 Re: xlog location arithmetic
Previous Message Tom Lane 2012-03-09 17:18:24 Re: xlog location arithmetic