| 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
| 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 |