On fre, 2010-05-21 at 16:31 +0200, Florian Pflug wrote:
I guess the justification is that with the same argument you could
argue that a view should have relkind 'r', since it's just an empty
table with a rewrite rule attached.
It used to be that way, but now a view doesn't have an empty table
2010/5/20 Pavel baro...@seznam.cz:
For this summer I have plan to make patch inplementing snapshot materialized
views (MV). I believe it will not be end of effort to implement more of MV.
But I / we need discuss MV syntax and exact behaviour so I have some
questions about that for all of you:
Pavel,
b) create MV syntax?
- CREATE MATERIALIZED VIEW mvname AS ..., I think it is quite
obvious to do so, but I had to ask
please do not fortget the:
create or replace MATERIALIZED VIEW
option.
And also the
DROP if exists
for the drop-command
Best wishes
Harald
--
GHUM Harald
Massa, Harald Armin c...@ghum.de writes:
please do not fortget the:
create or replace MATERIALIZED VIEW
option.
Please do. For something as complex as a table or view, CREATE OR
REPLACE is a lot more complicated than it is for simple objects like
functions. (See flamewar just a couple weeks
On May 21, 2010, at 15:59 , Robert Haas wrote:
2010/5/20 Pavel baro...@seznam.cz:
For this summer I have plan to make patch inplementing snapshot materialized
views (MV). I believe it will not be end of effort to implement more of MV.
But I / we need discuss MV syntax and exact behaviour so I
2010/5/20 Pavel baro...@seznam.cz:
d) what to do when someone use INSERT, UPDATE or DELETE against MV?
1 - raise error? - I prefer this option
+1, FWIW
2 - let commands change MV? (no chance to let changes propagate to
source tables, not for this summer :)
if pg lets user to DML
