From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Paul A Jungwirth <pj@illuminatedcomputing.com>,
        Erik Wienhold <ewie@ewie.name>, Said Assemlal <sassemlal@neurorx.com>,
        pgsql-hackers@postgresql.org, Haibo Yan <haibo.yan@hotmail.com>
Subject: Re: CREATE OR REPLACE MATERIALIZED VIEW
In-reply-to: 
 <CA+TgmoZ3S8DhnnhR0EFSAnJ2O2NvWpriaAg-jx=9Lg2AUEpP=A@mail.gmail.com>
References: <e4382244-6b55-450b-a4f0-32959056ade4@ewie.name>
 <e55c4930-f788-4bb0-a684-743621d6cfc5@neurorx.com>
 <7afe68b0-f983-4a9f-a1b4-32188cebbf38@ewie.name>
 <b74736cf-a4b4-4c32-8df1-d08abe9a14ed@ewie.name>
 <d4bf3ccf-5c2b-448d-ad16-59dd6fbe2a2e@ewie.name>
 <64495e31-0a91-4894-87f8-31451ee69f44@ewie.name>
 <bf64dad9-eaaa-4911-b447-13acee89ea80@ewie.name>
 <2724629.1743885428@sss.pgh.pa.us>
 <5cd7ec92-ee61-4080-8fb6-0aed6a51eeaf@ewie.name>
 <CA+renyW6-7aH74o-Gv2k+6emEXwznXxg=GkmTaKhDcresQQ9bg@mail.gmail.com>
 <6d710ac3-3a66-4b31-b35a-0b4d9afdda42@ewie.name>
 <CA+renyWJgjatyvJEKr9_GSnr3xr-sqLfhLR+rvw3MSygowR9xA@mail.gmail.com>
 <CA+renyW8xM3wycsYCk7nDkx4ytTNLNntaGh5-4CXNi-ns8dCOw@mail.gmail.com>
 <CA+TgmoZ3S8DhnnhR0EFSAnJ2O2NvWpriaAg-jx=9Lg2AUEpP=A@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Fri, 14 Aug 2026 13:34:45 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3774196.1786730718.1@sss.pgh.pa.us>
Date: Fri, 14 Aug 2026 14:05:18 -0400
Message-ID: <3774197.1786730718@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3774197.1786730718%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.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.

			regards, tom lane