Re: Materialized views WIP patch - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Materialized views WIP patch
Date
Msg-id 20121127144137.127680@gmx.com
Whole thread Raw
In response to Materialized views WIP patch  ("Kevin Grittner" <kgrittn@mail.com>)
Responses Re: Materialized views WIP patch  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
Dimitri Fontaine wrote:
> "Kevin Grittner" <kgrittn@mail.com> writes:
>> An ALTER MATERIALIZED VIEW option was my first thought on syntax
>> to do what LOAD does in the current patch. But it bothered me
>> that I couldn't think of any other cases where ALTER
>> <some-object-type> only changed the data contained within the
>> object and had no other impact. Are you both really comfortable
>> with an ALTER MATERIALIZED VIEW which has no effect other than
>> to update the data? It seems wrong to me.
> 
> I think you can already do that with some clever use of alter
> table ... type using, or alter table set default.

You mean, specifying an ALTER TABLE which appears to specify a
change to some non-data aspect of a table but which is really
setting it to the existing state? And it therefore rewrites the
table? I suppose that with USING you could actually even have it
rewritten with data different from what was there before without
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.

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.

-Kevin



pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Materialized views WIP patch
Next
From: Phil Sorber
Date:
Subject: Re: [WIP] pg_ping utility