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
