Re: CREATE OR REPLACE MATERIALIZED VIEW

From: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
To: Erik Wienhold <ewie(at)ewie(dot)name>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 16:28:05
Message-ID: CA+renyW8xM3wycsYCk7nDkx4ytTNLNntaGh5-4CXNi-ns8dCOw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 5, 2026 at 12:17 PM Paul A Jungwirth
<pj(at)illuminatedcomputing(dot)com> wrote:
>
> There are some issues with Tom's rule that OR REPLACE should give the
> same result as if you said CREATE. Potentially moving the tablespace
> (because the default differs from the old matview's value) and causing
> a table rewrite is a big effect, so let's at least document that it
> might happen. More seriously, this can leave your indexes stranded in
> the old tablespace, different from the matview's. That's not a state
> you can normally achieve, so it seems risky for us and confusing for
> users. I'm sure we don't want to sign up for handling that case going
> forward. So if the tablespace changes, should we rewrite the indexes
> too?

Sorry, I don't know what I was thinking here: of course you can put an
index in a different tablespace than its table (or matview). Still, it
does possibly break Tom's principle that CREATE OR REPLACE should give
you the same result with or without a prior object. So if we are
moving the matview's heap, maybe we should move its indexes too. Or
maybe not: they have their own CREATE commands and are really separate
objects. Whatever we do, it seems worth documenting.

Yours,

--
Paul ~{:-)
pj(at)illuminatedcomputing(dot)com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pierre Forstmann 2026-08-14 16:28:12 Re: Define MXID acronym in documentation
Previous Message Tom Lane 2026-08-14 16:27:47 Re: Redundant qualifier elimination