Kevin Grittner <kgri...@ymail.com> > There was one minor syntax issue not addressed by Noah, nor much > discussed in general that I didn't want to just unilaterally > choose; but given that nobody seems to care that much I will put > forward a proposal and do it that way tomorrow if nobody objects. > Before this patch tables were the only things subject to > truncation, but now materialized views can also be truncated. So > far we have been treating TABLE as a noise word in the truncate > command. I assume we still want to allow tables to be truncated > with or without the word. The question is what to do about > materialized views, and wheter both can be specified on a single > TRUNCATE statement. I propose that we allow TABLE or MATERIALIZED > VIEW to be specified, or that part of the statement to be left out. > I propose that either type of object be allowed unless one or the > other is specified and the object to be truncated is not of that > kind. So you could mix both kinds on one statement, so long as you > didn't specify either kind.
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? -- 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
