From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Marko Tiikkaja <pgmail(at)joh(dot)to>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Materialized views WIP patch |
Date: | 2013-02-21 15:19:57 |
Message-ID: | 20130221151957.GA23876@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On 2013-02-21 07:10:09 -0800, Kevin Grittner wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2013-02-21 15:26:06 | Re: Materialized views WIP patch |
Previous Message | Kevin Grittner | 2013-02-21 15:18:42 | Re: Materialized views WIP patch |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-02-21 15:21:34 | Re: FDW for PostgreSQL |
Previous Message | Kevin Grittner | 2013-02-21 15:18:42 | Re: Materialized views WIP patch |