On 2/20/13 5:03 PM, Kevin Grittner wrote:
> Peter Eisentraut <peter_e@gmx.net> wrote:
>> On 2/20/13 2:30 PM, Kevin Grittner wrote:
>>>> Are there TRUNCATE triggers on materialized views?
>>> No. Nor SELECT, INSERT, UPDATE, or DELETE triggers. You can't
>>> create a trigger of any type on a materialized view. I don't
>>> think that would interfere with event triggers, though.
>>
>> More generally, I would consider the invalidation of a
>> materialized view a DDL command, whereas truncating a table is a
>> DML command.
>
> The force of that assertion is somewhat undercut by the fact that
> the ExecuteTruncate() function does exactly what needs to be done
> to discard the data in a materialized view and make it appear as
> non-scannable. Even if we dress it up with different syntax, it's
> not clear that we wouldn't build a TruncateStmt in the parser and
> pass it through exactly the same execution path. We would just
> need to look at the relkind to generate a different command tag.
This is a fall-out of the implementation, and that's fine (although I'd
personally still be in favor of putting that state in the catalog, not
into the block count on disk, effectively), but I'm talking about the
external interfaces we present.
>> This has various implications with triggers, logging,
>> permissions. I think it's not good to mix those two.
>
> Could you give a more concrete example of where you see a problem?
* Logging: You can set things to log DDL commands only. I would want a
MV invalidation to be logged.
* Permissions: There is a TRUNCATE permission, would that apply here?
There is no refresh permission.
* Triggers: There are TRUNCATE triggers, but they don't apply here.
* Triggers: I don't know how event triggers work, but I'd like
materialized view events to be grouped together somehow.
* Don't know the opinion of sepgsql on all this.
I think what this all comes down to, as I've mentioned before, is that
the opposite of this proposed truncate operation is the refresh
operation, and that is a DDL command under ALTER MATERIALIZED VIEW.
Both of these fundamental operations -- truncate/refresh,
invalidate/validate, empty/refill, whatever -- should be grouped
together somehow, as far as syntax, as well logging, permissions,
trigger handling, and so on are concerned. You don't need a new command
or key word for this. How about ALTER MATERIALIZED VIEW DISCARD?