> I would like to know what operations you plan to support independently
> of the command names. I may have missed much earlier in the discussion
> but then I suspect things have evolved since then.
>
> It sounds like you want to support:
>
> 1) Selecting from materialized viws
> 2) Manually refreshing materialized views
> 3) Manually truncating materialized views
Maybe plus?
4) Automatically dropping materialized views if underlying table(s)
are dropped/altered
Or this has to be done manually?
> And explicitly not support
>
> 1) Automatically rewriting queries to select from matching views
> 2) Incrementally refreshing materialized views
> 3) Manual DML against data in materialized views (except truncate
> which is kind of DDL)
> 4) Keeping track of whether the data in the materialized view is up to date
>
> I have to say I find this model a bit odd. It seems the UI you're
> presenting is that they're basically read-only tables that the
> database will fill in the data for automatically. My mental model of
> materialized views is that they're basically views that the database
> guarantees a different performance characteristic for.
>
> I would expect a materialized view to be up to date all the time. If
> we don't support incremental updates (which seems like a fine thing
> not to support in a first cut) then I would expect any DML against the
> table to mark the view invalid and any queries against it to produce
> an error (or possibly go to the source tables using the view
> definition but that's probably a bad idea for most use cases). Ie.
> they should behave like a view at all times and have up to date
> information or fail entirely.
>
> I would expect a command like TRUNCATE MATERIALIZED VIEW to exist but
> I would expect it to be called something like INVALIDATE rather than
> TRUNCATE and dropping the storage is a side effect of simply telling
> the database that it doesn't need to maintain this materialized view.
> Though I could be convinced "truncate" is a good name as long as it's
> documented well.
>
> --
> greg
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers