On Fri, Aug 5, 2016 at 10:39 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2016-08-05 10:33:49 -0400, Tom Lane wrote:
>> Murat Tuncer <mtuncer@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