Message-ID: <6bf8a76ebf3215d2226dbc2245d351aae577e4c1.camel@j-davis.com>
Subject: Re: MAINTAIN privilege -- what do we need to un-revert it?
From: Jeff Davis <pgsql@j-davis.com>
To: Yugo NAGATA <nagata@sraoss.co.jp>
Cc: Noah Misch <noah@leadboat.com>, Michael Paquier <michael@paquier.xyz>,
 Nathan Bossart <nathandbossart@gmail.com>, pgsql-hackers@postgresql.org,
 Joe Conway <mail@joeconway.com>,  Robert Haas <robertmhaas@gmail.com>
Date: Thu, 01 Aug 2024 11:31:53 -0700
In-Reply-To: <20240731182012.45d8231608896732395fc81a@sraoss.co.jp>
References: <20240228165523.GA2435539@nathanxps13>
	 <31ae1bf73e8a1dae3ee7ef2dd43a9bbda1e1ab86.camel@j-davis.com>
	 <fe5d572b02d07d8e9940f9b518d900708e0b0166.camel@j-davis.com>
	 <20240630222344.db.nmisch@google.com> <ZozWqg0XCkiPCnop@paquier.xyz>
	 <23fac3b2a722373a52b92a12ee0f500821450f97.camel@j-davis.com>
	 <20240711125207.98.nmisch@google.com>
	 <d97b888293e7588164b602850969a4b7d9550cc5.camel@j-davis.com>
	 <20240712231149.0d.nmisch@google.com>
	 <8e0438821bddd4de198989e6ac0f9a2aa27cabeb.camel@j-davis.com>
	 <20240713214748.cb@rfd.leadboat.com.sranhm>
	 <20240726122630.70e889f63a4d7e26f8549de8@sraoss.co.jp>
	 <a7ce2ffa94cb26e40acf0ed8de857425f4d74727.camel@j-davis.com>
	 <20240731182012.45d8231608896732395fc81a@sraoss.co.jp>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu2 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/6bf8a76ebf3215d2226dbc2245d351aae577e4c1.camel%40j-davis.com>
Precedence: bulk

On Wed, 2024-07-31 at 18:20 +0900, Yugo NAGATA wrote:
> I agree that it might not be important, but I think adding the flag
> would be
> also helpful for improving code-readability because it clarify the
> function
> is used in the two cases. I attached patch for this fix (patch 0003).

Committed with one minor modification: I moved the boolean flag to be
near the other booleans rather than at the end. Thank you.

> Sure. I fixed the patch to remove 'param' from both functions. (patch
> 0002)

Committed, thank you.

> I also add the small refactoring around ExecCreateTableAs(). (patch
> 0001)
>=20
> - Remove matview-related codes from intorel_startup.
> =C2=A0 Materialized views are no longer handled in this function.
>=20
> - RefreshMatViewByOid is moved to just after create_ctas_nodata
> =C2=A0 call to improve code readability.
>=20

I'm not sure the changes in intorel_startup() are correct. I tried
adding an Assert(into->viewQuery =3D=3D NULL), and it fails because there's
another path I did not consider: "EXPLAIN ANALYZE CREATE MATERIALIZED
VIEW ...", which does not go through ExecCreateTableAs() but does go
through CreateIntoRelDestReceiver().

See:

https://postgr.es/m/20444c382e6cb5e21e93c94d679d0198b0dba4dd.camel@j-davis.=
com

Should we refactor a bit and try to make EXPLAIN use the same code
paths?

Regards,
	Jeff Davis