Re: CREATE OR REPLACE MATERIALIZED VIEW

From: Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>, Erik Wienhold <ewie(at)ewie(dot)name>, Said Assemlal <sassemlal(at)neurorx(dot)com>, pgsql-hackers(at)postgresql(dot)org, Haibo Yan <haibo(dot)yan(at)hotmail(dot)com>
Subject: Re: CREATE OR REPLACE MATERIALIZED VIEW
Date: 2026-08-14 18:27:26
Message-ID: CAMsGm5cSeROk+BhFUGY_eQuc9Mfy1Tg8nS=JeXYgS7V4xkmY-g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 14 Aug 2026 at 14:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > I think CREATE OR REPLACE is the wrong syntax here. I think what
> > people would most often want to do is edit the query used to refresh
> > the query without disturbing the existing data, indexes, or other
> > ancillary properties of the view in any way, but just changing what
> > happens on next refresh. We have CREATE OR REPLACE FUNCTION because
> > replacing a function in its entirety is a sensible thing to do, but we
> > don't have CREATE OR REPLACE TABLE because tables contain data that
> > you're unlikely to want to throw out. Materialized views are more like
> > tables in this respect: they have data. Granted, it can be
> > regenerated, but that's probably expensive.
>
> > So I'd propose that this should be a form of ALTER MATERIALIZED VIEW,
> > and that it be defined as suggested above, just replacing the refresh
> > query.
>
> This approach makes sense to me. Note that this would imply that the
> revised query has to still produce the same set of columns, else it's
> inconsistent with the MV's stored data (but maybe we could allow
> adding new columns at the end, as with tables). I suppose this means
> that if you want a different set of columns, you have no recourse
> short of dropping the MV.
>

I think it's important that there be a single command that can create a new
MV if it doesn't exist, or update its base query if it does. I shouldn't
have to explicitly write code to say if it doesn't exist then create it,
otherwise alter it to change the base query.

This sounds like CREATE OR REPLACE to me, even if there is something to
explain in the documentation about what happens to the existing data
(assuming it is currently populated). I don't think of CREATE OR REPLACE as
completely re-creating an object anyhow. Certainly it can't arbitrarily
replace a function (can't change return type) nor a view (can't remove or
change type of a column). It's OK if not all possible changes are supported
by the "OR REPLACE" part of the command.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-08-14 18:42:26 Re: missing PGDLLIMPORT in utils/acl.h after CVE-related "Invalidate plan cache after role changes"
Previous Message Nathan Bossart 2026-08-14 18:24:23 Re: Doc update proposal for the note on log_statement in the runtime config for logging page