Thread

Re: CREATE OR REPLACE MATERIALIZED VIEW

Erik Wienhold <ewie@ewie.name> — 2025-08-05T01:17:06Z

Sorry for the late reply but I haven't had the time to dig into this.
Here's v7 fixing the points below.

On 2025-04-05 22:37 +0200, Tom Lane wrote:
> * I think the proposal to deprecate IF NOT EXISTS is a nonstarter.
> Yeah, I don't like it much, but the standard of proof to remove
> features is amazingly high and I don't think it's been reached here.
> We're unlikely to remove IF NOT EXISTS for tables, and to the extent
> that matviews are like tables it's reasonable for them to have it too.

Yeah, I got that gist from the replies upthread and dropped that patch.

> * On the other hand, the semantics you've implemented for CREATE OR
> REPLACE are not right.  The contract for any form of C.O.R. is that
> it will either fail, or produce exactly the same object definition
> that you would have gotten from plain CREATE with no conflicting
> object.  The v6 code is visibly not doing that for properties such
> as tablespace --- if the command doesn't mention that, you don't
> get the default tablespace, you get whatever the old object had.

Thanks a lot.  I added a test case for that and v7-0001 now restores the
default options if none are specified.  Handling the default tablespace
is a bit cumbersome IMO because its name must be passed to
AlterTableInternal.  With v7-0002 I moved that to ATPrepSetTableSpace as
an alternative using the empty string as stand-in for the default
tablespace.  What do you think?

> * BTW, I'm inclined to think that WITH OLD DATA ought to fail
> if the command isn't replacing an existing matview.  It seems
> inconsistent to silently reinterpret it as WITH DATA, just as
> silently reinterpreting "no tablespace mentioned" as "use the
> old tablespace" is inconsistent.  I'm not dead set on that
> but it feels wrong.

Yes that also felt iffy to me.  It just didn't occur to me to simply
raise an error in ExecCreateTableAs.  Done so in v7-0003.

-- 
Erik Wienhold