From: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Joe Conway <mail(at)joeconway(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: MAINTAIN privilege -- what do we need to un-revert it? |
Date: | 2024-07-31 09:20:12 |
Message-ID: | 20240731182012.45d8231608896732395fc81a@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Fri, 26 Jul 2024 16:47:23 -0700
Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> Hello,
>
> Thank you for looking.
>
> On Fri, 2024-07-26 at 12:26 +0900, Yugo Nagata wrote:
> > Since this commit, matviews are no longer handled in
> > ExecCreateTableAs, so the
> > following error message has not to consider materialized view cases,
> > and can be made simple.
> >
> > /* SELECT should never rewrite to more or less than one
> > SELECT query */
> > if (list_length(rewritten) != 1)
> > elog(ERROR, "unexpected rewrite result for %s",
> > is_matview ? "CREATE MATERIALIZED VIEW" :
> > "CREATE TABLE AS SELECT");
>
> There's a similar error in refresh_matview_datafill(), and I suppose
> that should account for the CREATE MATERIALIZED VIEW case. We could
> pass an additional flag to RefreshMatViewByOid to indicate whether it's
> a CREATE or REFRESH, but it's an internal error, so perhaps it's not
> important.
Thank you for looking into the pach.
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).
> > Another my question is why RefreshMatViewByOid has a ParamListInfo
> > parameter.
>
> I just passed the params through, but you're right, they aren't
> referenced at all.
>
> I looked at the history, and it appears to go all the way back to the
> function's introduction in commit 3bf3ab8c56.
>
> > I don't understand why ExecRefreshMatView has one, either, because
> > currently
> > materialized views may not be defined using bound parameters, which
> > is checked
> > in transformCreateTableAsStmt, and the param argument is not used at
> > all. It might
> > be unsafe to change the interface of ExecRefreshMatView since this is
> > public for a
> > long time, but I don't think the new interface RefreshMatViewByOid
> > has to have this
> > unused argument.
>
> Extensions should be prepared for reasonable changes in these kinds of
> functions between releases. Even if the signatures remain the same, the
> parse structures may change, which creates similar incompatibilities.
> So let's just get rid of the 'params' argument from both functions.
Sure. I fixed the patch to remove 'param' from both functions. (patch 0002)
I also add the small refactoring around ExecCreateTableAs(). (patch 0001)
- Remove matview-related codes from intorel_startup.
Materialized views are no longer handled in this function.
- RefreshMatViewByOid is moved to just after create_ctas_nodata
call to improve code readability.
Regards,
Yugo Nagata
--
Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
Attachment | Content-Type | Size |
---|---|---|
v2-0003-Add-a-flag-to-RefreshMatviewByOid-to-indicate-whe.patch | text/x-diff | 5.9 KB |
v2-0002-Remove-ParamListInfo-argument-from-RefreshMatView.patch | text/x-diff | 2.7 KB |
v2-0001-Small-refactoring-around-ExecCreateTableAs.patch | text/x-diff | 4.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2024-07-31 09:27:58 | Re: Proposal: Document ABI Compatibility |
Previous Message | Hayato Kuroda (Fujitsu) | 2024-07-31 09:15:28 | RE: make pg_createsubscriber option names more consistent |