On Fri, Aug 5, 2016 at 10:39 AM, Andres Freund <and...@anarazel.de> wrote: > On 2016-08-05 10:33:49 -0400, Tom Lane wrote: >> Murat Tuncer <mtun...@citusdata.com> writes: >> > I recently hit a road blocker when I tried to create a truncate trigger on >> > a foreign table. trigger.c::CreateTrigger() function has explicit check to >> > block truncate trigger on foreign tables. >> >> That's good, because we don't implement TRUNCATE on foreign tables: there >> is nothing in the FDW API that would support it. Not much point in >> declaring a trigger for an event that can never happen. > > Well, allowing BEFORE triggers to return NULL or something, preventing > the execution of the rest, would be such an implementation, and also > independently useful.
I guess. I think if we're going to add support utility commands on foreign tables, we ought to think about all of the different utility commands that someone might want and what exactly we want the behavior to be. For example, consider CLUSTER or CREATE INDEX or VACUUM or ANALYZE. We might interpret TRUNCATE or CLUSTER as a request to dispatch the same request for the remote side, but ANALYZE can't mean that: it has to mean gather local statistics. And what if the other side is not PG and supports other operations that we don't have, like OPTIMIZE TABLE or DISENGAGE FTL? That isn't, strictly speaking, a reason to reject a patch that just allows TRUNCATE triggers on FDWs to "return NULL or something", but I can't get very excited about such a patch because I think the utility is fairly marginal. I'd rather have a little more of a plan than that before we go start tinkering. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
