On Tue, Jun 13, 2023 at 4:44 PM David Steele <da...@pgmasters.net> wrote: > On 6/13/23 06:09, Amit Langote wrote: > > On Sat, Jun 10, 2023 at 10:27 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Julien Rouhaud <rjuju...@gmail.com> writes: > >>> On Sat, Jun 10, 2023 at 08:56:47AM -0400, Tom Lane wrote: > >>>> - rte->relkind = 0; > >> > >>> and also handle that field in (read|out)funcs.c > >> > >> Oh, right. Ugh, that means a catversion bump. It's not like > >> we've never done that during beta, but it's kind of an annoying > >> cost for a detail as tiny as this. > > > > OK, so how about the attached? > > The patch looks good to me. I also tested it against pgAudit and > everything worked.
Thanks for the review. > I decided to go with the following because I think it > is easier to read: > > /* We only care about tables/views and can ignore subqueries, etc. */ > if (!(rte->rtekind == RTE_RELATION || > (rte->rtekind == RTE_SUBQUERY && rte->relkind == RELKIND_VIEW))) > continue; It didn't occur to me so far to mention it but this could be replaced with: if (rte->perminfoindex != 0) and turn that condition into an Assert instead, like the loop over range table in ExecCheckPermissions() does. > > I considered adding Assert(relkind == RELKIND_VIEW) in all places that > > have the "rte->rtekind == RTE_SUBQUERY && OidIsValid(rte->relid)" > > condition, but that seemed like an overkill, so only added one in the > > #ifdef USE_ASSERT_CHECKING block in ExecCheckPermissions() that > > f75cec4fff877 added. > > This seems like a good place for the assert. I added a comment above this Assert. I'd like to push this tomorrow barring objections. -- Thanks, Amit Langote EDB: http://www.enterprisedb.com
v2-0001-Retain-relkind-too-in-RTE_SUBQUERY-entries-for-vi.patch
Description: Binary data