Peter Eisentraut <pete...@gmx.net> wrote: > On 2/19/13 5:47 PM, Kevin Grittner wrote: >> When I went to do this, I hit a shift/reduce conflict, because >> with TABLE being optional it couldn't tell whether: >> >> TRUNCATE MATERIALIZED VIEW x, y, z; >> >> ... was looking for five relations or three. That goes away >> with MATERIALIZED escalated to TYPE_FUNC_NAME_KEYWORD. Is that >> OK? > > Is TRUNCATE even the right command here? For regular tables > TRUNCATE is a fast DELETE, which logically empties the table. > For materialized views, there is no deleting, so this command (I > suppose?) just invalidates the materalized view. That's not the > same thing.
Hmm. That's what Greg Stark just said, and I replied that nobody else had raised the issue in over three months. With Greg, that's two now. TRUNCATE MATERIALIZED VIEW discards any data which has been loaded into the MV, rendering it unavailable for scanning. Internally, it does do a truncate, exactly as truncate table. The resulting zero-length heap file is what is used to determine whether a materialized view is "scannable". When a CREATE WITH DATA or a REFRESH generates zero rows, an empty single page is created to indicate that it is scannable (valid to use in queries) but contains no rows. I agree that INVALIDATE is probably more descriptive, although it seems that there might be some even better word if we bikeshed enough. The question is, is it worth creating a new keyword to call the internal truncate function for materialized views, versus documenting that truncating a materialized view renders it invalid? Again, given the numbers that Tom presented a while back about the space requirements of every new keyword, I don't think this is enough of a gain to justify that. I still squirm a little about having used REFRESH, even though demand for that was overwhelming. > 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. -- Kevin Grittner 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
