Re: Materialized views WIP patch

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

In response to

Responses

Browse pgsql-committers by date

  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

Browse pgsql-hackers by date

  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