On 2013-02-21 07:10:09 -0800, Kevin Grittner wrote:
> Andres Freund <andres@2ndquadrant.com> wrote:
> > giving an error so its an easy to find distinction to a normal
> > table seems like a good idea.
>
> I'm not sure I understood your concerns entirely, but wonder
> whether this helps?:
To explain it a bit:
I assume that at some point matviews will get (auto-)updateable, just as
normal views recently got. In that case application programmers might
not be aware anymore that something is a view either because they just
don't know or because a table got converted into a matview after the
code was written.
Because of the potential wish for transparency (with security views as a
potential user) at least normal views might get the capability to be
TRUNCATEd directly, so it might be that matviews do as well.
> test=# \d
> List of relations
> Schema | Name | Type | Owner
> --------+-------+-------------------+---------
> public | bb | materialized view | kgrittn
> public | t | table | kgrittn
> public | tm | materialized view | kgrittn
> public | tmm | materialized view | kgrittn
> public | tv | view | kgrittn
> public | tvmm | materialized view | kgrittn
> public | tvv | view | kgrittn
> public | tvvm | materialized view | kgrittn
> public | tvvmv | view | kgrittn
> (9 rows)
>
> test=# truncate table tm;
> ERROR: "tm" is not a table
> test=# truncate materialized view t;
> ERROR: "t" is not a materialized view
> test=# truncate materialized view tm;
> TRUNCATE TABLE
> test=# truncate table t;
> TRUNCATE TABLE
Thats not bad.
But what if we allow TRUNCATE on views someday (possibly only if a
truncate trigger is defined). For consistency we might also want that on
matvies. Having a difference between TRUNCATE view; and TRUNCATE
MATERIALIZED VIEW; in that case sounds ugly to me.
What about DISABLE? DISCARD or DEALLOCATE would also be nice but it
seems hard to fit that into existing syntax.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
