Re: Materialized views WIP patch

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: "Kevin Grittner" <kgrittn(at)mail(dot)com>
Cc: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Pgsql Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Materialized views WIP patch
Date: 2012-11-27 15:02:58
Message-ID: m2zk23ulzx.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Kevin Grittner" <kgrittn(at)mail(dot)com> writes:
> changing the structure of the table. Somehow I don't find that
> pursuasive as an argument for what ALTER MATERIALIZED VIEW should
> rescan the source relations and build a whole new set of data for
> exactly the same MV definition.

Fair enough.

> Consider that in relational theory a table is considered a relation
> variable. ALTER is supposed to change the definition of the
> variable in some way. Other statements are used to change the value
> contained in the variable. Sure there are some grey areas already,
> but I don't see where we need to muddy the waters in this case.

Under that light, using ALTER is strange indeed. I still don't like
using LOAD that much, allow me to try a last syntax proposal. Well all I
can find just now would be:

UPDATE MATERIALIZED VIEW mv FOR EACH ROW;
UPDATE MATERIALIZED VIEW mv FOR EACH STATEMENT [ CONCURRENTLY ];

The only value of such a proposal is that it's not LOAD and it's still
not introducing any new keyword. Oh it's also avoiding to overload the
SNAPSHOT keyword. Well, it still does not look like the best candidate.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2012-11-27 15:07:34 Re: foreign key locks
Previous Message Phil Sorber 2012-11-27 14:43:30 Re: [WIP] pg_ping utility